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MECHANICAL  VERIFICATION  OF  TIMED  AUTOMATA:  A  CASE  STUDY 


1  Introduction 

Researchers  have  proposed  many  innovative  formal  methods  for  developing  real-time  systems  [14].  Such 
methods  are  intended  to  give  system  developers  and  customers  greater  confidence  that  real-time  systems 
satisfy  their  requirements,  especially  their  critical  requirements.  However,  applying  formal  methods  to 
practical  systems  raises  a  number  of  challenges: 

1.  How  can  the  artifacts  produced  in  applying  formal  methods  (e.g.,  formal  descriptions,  formal  proofs)  be 

made  understandable  to  the  developers? 

2.  To  what  extent  can  software  developers  use  the  formal  methods,  including  formal  proof  methods? 

3.  What  kinds  of  tools  can  aid  developers  in  applying  formal  methods? 

The  purpose  of  this  report  is  to  describe  the  results  of  a  case  study  in  which  these  issues  were  investigated. 
In  particular,  we  are  interested  in  how  a  mechanical  proof  system  can  support  formal  reasoning  about  real¬ 
time  systems  using  a  specific  mathematical  model.  By  validating  human  proofs  of  timing  properties,  such  a 
system  can  increase  confidence  that  a  given  specification  satisfies  critical  properties  of  interest. 

In  the  case  study,  we  applied  the  mechanical  proof  system  PVS  [31,  33]  to  a  solution  of  the  Generalized 
Railroad  Crossing  (GRC)  problem  [16,  12,  13].  The  solution  is  based  on  the  Lynch- Vaandrager  timed 
automata  model  [28,  27]  and  uses  invariant  and  simulation  mapping  techniques.  Our  approach,  which 
should  generalize  to  proving  properties  about  real-time  systems  specified  in  any  model,  was  to  develop  a 
template,  containing  a  set  of  common  theories,  a  common  structure,  and  specialized  proof  strategies,  useful 
in  constructing  timed  automata  models  and  proving  properties  about  them.  To  specify  a  particular  timed 
automata  model  and  its  properties,  the  user  fills  in  the  template.  The  user  then  may  use  the  proof  system 
to  verify  that  the  model  satisfies  the  properties.  This  approach  simplifies  both  the  specification  process  and 
the  proof  process  because  users  can  reason  in  a  specialized  domain,  the  timed  automata  model;  they  need 
not  master  the  base  logic  and  the  user  interface  of  the  full  automatic  proof  system.  The  techniques  we 
have  developed  using  this  approach  have  become  the  basis  for  a  tool  TAME  (Timed  Automata  Modeling 
Environment),  which  we  are  continuing  to  develop. 

Like  other  approaches  to  formal  reasoning  about  real-time  systems,  such  as  SMV  [29,  8],  HyTech  [18], 
and  COSPAN  [19],  our  approach  is  based  on  a  formal  automata  model.  Moreover,  like  these  other  approaches, 
our  methods  can  be  used  to  prove  properties  of  particular  automata  and,  like  COSPAN,  to  prove  simulations 
between  automata.  However,  our  approach  is  different  from  other  approaches  in  two  major  ways.  First,  the 
properties  we  prove  are  expressed  in  a  standard  logic  with  universal  and  existential  quantification.  This  is 
in  contrast  to  most  other  approaches,  where  the  properties  to  be  proved  are  expressed  either  in  a  temporal 
logic,  such  as  CTL  or  Ictl,  or  in  terms  of  automata.  Second,  unlike  other  automata-based  methods,  the 
generation  of  proofs  in  our  method  is  not  completely  automatic.  Rather,  our  method  supports  the  checking 
of  human-developed  proofs  of  the  properties  based  on  deductive  reasoning.  By  this  means,  and  by  providing 
templates  for  developing  specifications,  we  largely  eliminate  the  need  for  ingenuity  in  expressing  a  problem 
using  the  special  notations  and  special  logics  of  a  verification  system. 

Requiring  some  interaction  with  an  automatic  theorem  prover  does  demand  a  higher  level  of  sophistication 
from  the  user.  But  by  supporting  reasoning  about  automata  at  a  high  level  of  abstraction,  we  make  it  possible 
to  prove  more  powerful  results  than  can  be  done  with  tools  requiring  more  concrete  descriptions  of  automata 
and  avoid  the  state  explosion  problem  inherent  in  other  automata-based  approaches. 

In  our  approach,  each  mechanically  generated  proof  closely  follows  a  corresponding  English  language 
proof.  Such  a  proof  is  more  likely  to  be  understandable  and  convincing  to  developers  familiar  with  the 
specialized  timed  automata  domain  and  comfortable  with  English  language  proofs.  Our  study  identified 
proof  techniques,  such  as  induction,  that  were  most  useful  in  proofs  about  timed  automata  models.  We 
designed  PVS  strategies  that  automatically  do  the  standard  parts  of  proofs  having  a  standard  structure.  A 
major  goal  was  to  develop  PVS  versions  of  hand  proofs  that  could  be  understood  and,  in  some  cases,  even 
produced  using  appropriate  tools,  by  domain  experts  who  are  able  to  understand  hand  proofs  but  who  are 
not  PVS  experts. 

In  Section  2,  the  report  reviews  the  GRC  benchmark,  the  timed  automata  model,  and  PVS.  Section  3 
presents  three  theories  that  underlie  the  timed  automata  model  and  gives  their  representation  in  PVS.  One 
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of  these  theories,  the  theory  machine,  contains  as  a  theorem  the  induction  principle  used  to  prove  state 
invariants  in  the  timed  automata  model.  Section  4  presents  a  template  for  defining  timed  automata  models 
in  PVS  and  an  example  of  how  the  template  can  be  instantiated  to  specify  the  Trains  component  of  the 
timed  automata  solution  of  the  GRC.  Section  5  presents  a  hand  proof  and  the  corresponding  PVS  proof  of 
the  induction  principle  given  in  the  theory  machine.  To  illustrate  how  our  approach  can  be  used  to  check 
a  complex  proof,  Section  5  presents  the  hand  proof  of  the  Safety  Property  (see  the  GRC  problem  statement 
below)  along  with  the  corresponding  PVS  proof.  Sections  6,  7  and  8  present  major  results  of  our  case  study, 
a  discussion  of  related  work,  and  some  early  conclusions.  Section  9  gives  an  overview  of  recent  developments 
regarding  TAME. 

Additional  detail  on  the  work  done  in  the  study  is  provided  in  the  appendices.  Appendix  A  presents 
the  theory  atexecs  of  admissible  timed  executions  of  timed  automata,  the  fourth  underlying  theory  for  the 
timed  automata  model.  Appendix  B  contains  the  full  specifications  of  four  example  timed  automata  from 
[13,  12].  Appendix  C  presents  the  PVS  strategies  that  were  used  in  proofs  of  properties  of  the  example  timed 
automata.  The  full  set  of  proofs  of  state  invariants  of  the  example  timed  automata  is  shown  in  Appendix  D. 
An  example  ad  hoc  proof  of  a  property  of  admissible  timed  executions  of  timed  automata,  together  with  a 
discussion  of  feasibility  of  better  PVS  strategies  to  support  it  and  similar  proofs,  is  presented  in  Appendix  E. 
Appendix  F  exhibits  an  alternative  timed  automaton  template  with  an  example  of  its  use. 

A  briefer  version  of  this  report  can  be  found  in  [1]. 


2  Background 

2.1  The  Generalized  Railroad  Crossing  Problem 

The  purpose  of  the  GRC  problem  is  to  provide  a  benchmark  for  comparing  different  real-time  formalisms. 
Although  it  is  a  “toy”  problem,  the  different  specifications  and  solutions  of  the  GRC  benchmark  provide 
many  insights  into  the  strengths  and  weaknesses  of  different  formal  approaches  for  representing  and  reasoning 
about  real-time  systems.  The  problem  statement  is  as  follows: 

The  system  to  be  developed  operates  a  gate  at  a  railroad  crossing.  The  railroad  crossing  I  lies  in  a  region 
of  interest  R,  i.e.,  I  C  R.  A  set  of  trains  travel  through  R  on  multiple  tracks  in  both  directions.  A  sensor 
system  determines  when  each  train  enters  and  exits  region  R.  To  describe  the  system  formally,  we  define  a 
gate  function  g(t)  €  [0,  90],  where  g(t)  =  0  means  the  gate  is  down  find  g(t)  =  90  means  the  gate  is  up.  We 
define  a  set  {A*}  of  occupancy  intervals ,  where  each  occupancy  interval  is  a  time  interval  during  which  one 
or  more  trains  are  in  I.  The  ith  occupancy  interval  is  represented  as  A;  =  [t*,  i/i],  where  tv  is  the  time  of  the 
ith  entry  of  a  train  into  the  crossing  when  no  other  train  is  in  the  crossing  and  Vi  is  the  first  time  since  r* 
that  no  train  is  in  the  crossing  (i.e.,  the  train  that  entered  at  x*  has  exited,  as  have  any  trains  that  entered 
the  crossing  after  xa). 

Given  two  constants  £i  and  £2,  £1  >  0,  £2  >  0,  the  problem  is  to  develop  a  system  to  operate  the  crossing 
gate  that  satisfies  the  following  two  properties: 

Safety  Property:  t  €!  LhAi  g(t)  =  0  (Gate  is  down  during  all  occupancy  intervals.) 

Utility  Property:  t  £  U ifa  —  £1,  Vi  -f  £2]  =>  g(t)  =  90  (Gate  is  up  when  no  train  is  in  /.) 


2.2  The  Timed  Automata  Model 

The  formal  model  used  in  [12, 13]  to  specify  the  GRC  problem  and  to  develop  and  verify  a  solution  represents 
both  the  computer  system  and  its  environment  as  timed  automata ,  according  to  the  definitions  of  Lynch  and 
Vaandrager  [28,  27].  A  timed  automaton  is  a  very  general  automaton,  i.e.,  a  labeled  transition  system. 
It  need  not  be  finite-state:  for  example,  the  state  can  contain  real-valued  information  such  as  the  current 
time  or  the  position  of  a  train  or  crossing  gate.  This  makes  timed  automata  suitable  for  modeling  not  only 
computer  systems  but  also  real-world  entities  such  as  trains  and  gates.  The  timed  automata  model  describes 
a  system  as  a  set  of  timed  automata,  interacting  by  means  of  common  actions.  In  solving  the  GRC  problem 
using  timed  automata,  separate  timed  automata  represent  the  trains,  the  gate,  and  the  computer  system;  the 
common  actions  are  sensors  reporting  the  arrival  of  trains  and  actuators  controlling  the  raising  and  lowering 
of  the  gate.  Below,  we  define  the  special  case  of  timed  automata,  based  on  the  definitions  in  [12,  13],  which 
we  used  in  our  case  study. 
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Timed  Automata.  A  timed  automaton  A  consists  of  five  components: 

•  states(A)  is  a  (finite  or  infinite)  set  of  states. 

•  start(A)  C  states(A)  is  a  nonempty  (finite  or  infinite)  set  of  start  states. 

•  A  mapping  now  from  states(A)  to  R~°,  the  non-negative  real  numbers. 

•  acts(A)  is  a  set  of  actions  (or  events),  which  include  special  time-passage  actions  u(A t),  where  At  is  a  positive 
real  number,  and  non-time-passage  actions,  classified  as  input  and  output  actions,  which  are  visible ,  and  internal 
actions. 

•  steps(A)  :  states(A)  x  acts(A)  ->  states(A)  is  a  partial  function  that  defines  the  possible  steps  (i.e.,  transitions). 

This  is  a  restricted  definition  that  requires  steps(A)  to  be  a  function.  The  most  general  definition  of 
timed  automata  permits  steps(A)  to  be  an  arbitrary  relation.  Straightforward  modifications  to  our  approach 
would  handle  the  general  case. 

Timed  Executions  and  Reachability.  A  trajectory  is  either  a  single  state  or  a  continuous  series  of  states 
connected  by  time  passage  events.  A  timed  execution  fragment  is  a  finite  or  infinite  alternating  sequence 
a  =  wo7riWi7T2W2  *  •  •,  where  each  Wj  is  a  trajectory  and  each  7 tj  is  a  non-time-passage  action  that  “connects” 
the  final  state  s  of  the  preceding  trajectory  wj- 1  with  the  initial  state  s'  of  the  following  trajectory  wj .  A 
timed  execution  is  a  timed  execution  fragment  in  which  the  initial  state  of  the  first  trajectory  is  a  start  state. 
A  state  of  a  timed  automaton  is  defined  to  be  reachable  if  it  is  the  final  state  of  the  final  trajectory  in  some 
finite  timed  execution  of  the  automaton. 

A  timed  execution  is  admissible  if  the  total  amount  of  time-passage  is  infinity.  We  use  the  notation 
atexecs(A)  to  represent  the  set  of  admissible  timed  executions  of  timed  automaton  A .  The  notion  of  ad¬ 
missible  timed  executions  is  important  in  expressing  the  Utility  Property  (and  other  properties  defined  over 
time  intervals  rather  than  time  points)  and  in  defining  simulation  relations  between  timed  automata. 

MMT  Automata.  An  MMT  automaton  [30,  25,  24]  is  a  special  case  of  the  general  Lynch- Vaandrager 
timed  automata  model,  whose  states  can  be  represented  as  having  a  “basic”  part  representing  the  state  of 
an  underlying  I/O  automaton  [26],  a  current  time  component  now,  and  first  and  last  components  that  define 
lower  and  upper  time  bounds  on  each  action. 

Invariants  and  Simulation  Mappings.  An  invariant  of  a  timed  automaton  is  any  property  that  is  true 
of  all  reachable  states,  or  equivalently,  any  set  of  states  that  contains  all  the  reachable  states.  A  simulation 
mapping  [28,  27,  24]  relates  the  states  of  one  timed  automaton  A  to  the  states  of  another  timed  automaton  B 
with  the  same  visible  actions  in  such  a  way  that  the  visible  actions  and  their  timings  in  any  admissible  timed 
execution  of  A  correspond  to  those  in  some  admissible  timed  execution  of  B.  The  existence  of  a  simulation 
mapping  from  A  to  B  thus  implies  that  each  visible  behavior  of  automaton  A  is  contained  in  the  set  of 
visible  behaviors  of  automaton  B.  Proofs  of  both  state  invariants  and  simulation  mappings  have  a  standard 
structure  with  a  base  case  involving  start  states  and  a  case  for  each  possible  action. 

2.3  PVS 

The  following  description  of  PVS  is  taken  from  [35]: 

PVS  (Prototype  Verification  System)  [33]  is  an  environment  for  specification  and  verification  that  has  been 
developed  at  SRI  International’s  Computer  Science  Laboratory.  In  comparison  to  other  widely  used  verifi¬ 
cation  systems,  such  as  HOL  [11]  and  the  Boyer-Moore  prover  [7],  the  distinguishing  characteristic  of  PVS 
is  that  it  supports  both  a  highly  expressive  specification  language  and  a  very  effective  interactive  theorem 
prover  in  which  most  of  the  low-level  proof  steps  are  automated.  The  system  consists  of  a  specification  lan¬ 
guage,  a  parser,  a  type  checker,  and  an  interactive  proof  checker.  The  PVS  specification  language  is  based  on 
higher-order  logic  with  a  richly  expressive  type  system  so  that  a  number  of  semantic  errors  in  specification 
can  be  caught  by  the  type  checker.  The  PVS  prover  consists  of  a  powerful  collection  of  inference  steps  that 
can  be  used  to  reduce  a  proof  goal  to  simpler  subgoals  that  can  be  discharged  automatically  by  the  primitive 
proof  steps  of  the  prover.  The  primitive  proof  steps  involve,  among  other  things,  the  use  of  arithmetic  and 
equality  decision  procedures,  automatic  rewriting,  and  BDD-based  boolean  simplification. 
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machine  [  states,  actions:  TYPE, 

enabled:  [actions,states  ->  bool], 
trans:  [actions, states  ->  states], 
start:  [states  ->  bool]  ]  :  THEORY 

BEGIN 

s,sl:  VAR  states 
a:  VAR  actions 
n,nl:  VAR  nat 

Inv:  VAR  [states  ->  bool]; 

reachable„hidden(s,n):  RECURSIVE  bool  = 

IF  n  =  0  THEN  start(s) 

ELSE  (EXISTS  a,  s  1 :  reachable_hidden(s  1  ,n  -  l )  &  enabled(a,s  1 )  &  s  =  trans(a,s  1 )) 

ENDIF 

MEASURE  n 

■sr  reachable(s):  bool  =  (EXISTS  n:  reachable_hidden(s,n)) 
base(Inv) :  bool  =  (FORALL  s:  start(s)  =>  Inv(s)) 
inductstep(Inv) :  bool  = 

(FORALL  s,  a:  reachable(s)  &  Inv(s)  &  enabled(a,s)  =>  Inv(trans(a,s))) 
inductthm(Inv):  bool  =  base(Inv)  &  inductstep(Inv)  =>  (FORALL  s:  reachable(s)  =>  Inv(s)) 
machine_induct:  THEOREM  (FORALL  Inv:  inductthm(Inv)) 

END  machine 


Figure  1:  The  Theory  machine. 

A  major  goal  of  our  study  was  to  evaluate  PVS  as  a  basis  for  suitable  theorem  proving  support  for  establishing 
properties  of  specifications  in  our  specialized  domain.  Our  experience  with  PVS  is  summarized  in  Section  8. 


3  Underlying  Theories  for  Timed  Automata 

Our  approach  to  specifying  timed  automata  in  PVS  is  to  use  a  template  that  defines  a  set  of  underlying 
theories  and  provides  a  standard  framework  and  standard  names  and  definitions  for  each  specification.  The 
standard  framework  can  be  defined  in  more  than  one  way.  In  Section  6,  we  discuss  the  tradeoffs  in  selecting 
a  framework.  Below,  we  introduce  three  underlying  theories  shared  by  all  timed  automata:  the  theory 
machinie,  which  contains  as  a  theorem  the  induction  principle  upon  which  we  base  our  specialized  induction 
strategies;  the  theory  states,  which  defines  the  components  of  states;  and  the  theory  time.thy,  which  uses 
the  extended  non-negative  real  numbers  to  represent  time  values.1 

3-1  The  Theory  machine 

Figure  1  shows  the  PVS  specification  of  the  theory  machine.  This  theory,  which  defines  the  meaning  of 
mathematical  induction  in  the  context  of  the  timed  automata  model,  is  the  core  of  our  general  PVS  strategy 
for  performing  the  standard  steps  of  state  invariant  proofs.  It  is  also  of  interest  because  Section  5  uses 
the  proof  of  the  induction  principle  as  an  example  of  how  a  hand  proof  can  be  translated  into  PVS.  The 
theory  consists  of  the  induction  principle  along  with  the  definitions  needed  for  its  statement.  Most  of  these 
definitions  are  straightforward. 

The  theory  has  the  five  parameters  needed  to  define  a  timed  automaton:  states ,  the  automaton’s  states; 
actions ,  its  input  alphabet;  start ,  its  start  states;  enabled ,  the  guards  on  state  transitions;  and  trans,  the 
automaton’s  transition  function.  The  two  parameters  states  and  actions  are  simply  type  parameters.  The 

1An  additional  theory,  atexecs,  which  we  do  not  need  for  the  examples  in  Section  5,  defines  atexecs(A ),  the  admissible 
timed  traces  of  automaton  A.  We  present  this  theory  in  Appendix  A. 
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states  [  actions,  MMTstates,  time  :  TYPE,  fin_pred  :  [time  ->  bool]  ] :  THEORY 
BEGIN 

states:  TYPE  =  [#  basic:  MMTstates,  now:  (fin_pred),  first,  last:  [actions  ->  time]  #] 
END  states  _ 


Figure  2:  The  Theory  states. 

actual  parameters  in  an  instantiation  of  the  template  are  the  states  and  actions  types  (i.e.,  the  sets  of  possible 
values  of  states  and  actions)  of  some  particular  timed  automaton.  The  parameter  start  is  instantiated  by 
a  predicate  on  states  true  only  for  start  states,  and  the  parameter  enabled  by  a  predicate  on  actions  and 
states  true  only  when  the  action  is  enabled  in  the  state.  The  parameter  trans  is  instantiated  by  a  function 
that  maps  an  action  and  a  state  to  a  new  state.  Together,  enabled  and  trans  define  the  steps  of  the  timed 
automaton. 

The  body  of  the  theory  describes  six  predicates  used  to  define  the  induction  principle.  The  first  predicate 
Inv  represents  an  arbitrary  predicate  (i.e.,  an  invariant)  on  states.  The  second  predicate  reachable-hidden  is 
true  of  a  state  s  and  natural  number  n  if  s  is  reachable  from  a  start  state  in  n  steps.  The  MEASURE  clause 
of  this  definition  permits  PVS  to  verify  during  type  checking  that  the  predicate  reachable-hidden  is  always 
well  defined,  i.e.,  that  its  (recursive)  definition  terminates  on  all  arguments.  The  predicate  reachable  is  true 
of  a  state  s  if  reachable-hidden  is  true  for  s  and  some  natural  number  n.  (We  have  proved  in  PVS  that  this 
definition  of  reachability  is  equivalent  to  the  definition  given  in  Section  2.2.2)  The  next  two  predicates  define 
the  two  parts  of  the  induction  principle:  base,  which  states  that  the  given  invariant  holds  for  the  base  case, 
and  inductstep,  which  states  that  the  invariant  is  preserved  by  every  enabled  action  on  a  reachable  state. 
Finally,  the  predicate  inductthm  on  invariants  states  that  an  invariant  is  true  if  it  holds  in  the  base  case  and 
is  preserved  in  the  induction  step. 

3.2  The  Theory  states 

Figure  2  gives  the  PVS  specification  of  the  very  simple  theory  states.  The  main  purpose  of  this  theory  is  to 
define  a  standard  record  structure  and  standard  temporal  information  for  the  states  of  an  automaton.  The 
theory  has  four  parameters.  The  first  three,  actions,  MMTstates,  and  time,  are  type  parameters.  The  fourth 
parameter  fin-pred  is  a  predicate  that  is  true  if  its  argument,  a  time  value,  is  finite. 

The  body  of  the  theory  contains  a  single  statement  defining  the  record  structure  of  a  state.  The  theory 
requires  that  a  state  contain  a  basic  component,  a  time  component,  and  components  first  and  last  representing 
time  restrictions  on  specified  actions.  In  PVS,  the  symbols  “[#  •  -  •  #]”  are  record  brackets.  The  basic 
component  contains  all  of  the  nontimed  information  in  the  state  along  with  any.  nonstandard  absolute  time 
markers.  The  now  component  is  an  element  of  type  time  satisfying  the  predicate  fin-pred  (that  is,  now  is 
finite).  The  first  and  last  components  specify  the  upper  and  lower  time  bounds  on  each  action.3 

Both  the  theory  machine  and  the  theory  states  have  parameters  that  are  functions.  The  ability  to  define 
a  theory  with  function  parameters  and  to  define  states  with  components  that  are  functions  exists  because 
PVS  has  a  higher-order  logic.  In  general,  using  a  higher-order  logic  facilitates  the  creation  of  template 
specifications.  Section  8  describes  other  advantages  of  a  higher-order  logic. 


3.3  The  Theory  time_thy 

Figure  3  gives  the  PVS  specification  of  the  data  type  time  and  the  theory  time_thy.  In  a  timed  automaton, 
each  state  has  an  associated  time  in  R-°.  However,  in  the  time  bounds  associated  with  actions,  infinity  is 
allowed  as  a  time  value  to  represent  the  case  when  no  final  deadline  on  an  action  exists.  Thus,  to  represent 
time  in  our  template,  we  require  the  union  type,  R-°  U  {oo}. 

2 See  Lemma  reachability  in  the  theory  opspec_atexecs^aux  in  Appendix  B.3. 

3  Although  the  type  states  is  designed  to  make  it  easy  to  express  an  MMT  automaton  as  a  timed  automaton,  it  is  general 
enough  for  any  timed  automaton. 
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time:  DATATYPE 
BEGIN 

fintime(dur:  { r:real|r>=0 } ):  fintime? 
infinity:  inftime? 

END  time 

time_thy:  THEORY 
BEGIN 

IMPORTING  time 
zero:  time  =  fintime(O); 

<=  (tl,t2:time):bool  =  IF  fintime?(tl)  &  fintime?(t2)  THEN  dur(tl)  <=  dur(t2) 

ELSE  inftime?(t2)  ENDIF; 

>=  (tl,t2:time):bool  =  IF  fintime?(tl)  &  fintime?(t2)  THEN  dur(tl)  >=  dur(t2) 

ELSE  inftime?(t  1 )  ENDIF; 

<  (tl,t2:time):bool  =  IF  fintime?(tl)  &  fintime?(t2)  THEN  dur(tl)  <  dur(t2) 

ELSE  NOT(inftime?(t  1 ))  &  inftime?(t2)  ENDIF; 

>  (tl,t2:time):booI  =  IF  fintime?(tl)  &  fintime?(t2)  THEN  dur(tl)  >  dur(t2) 

ELSE  NOT(inftime?(t2))  &  inftime?(tl)  ENDIF; 

+  (tl,t2: time): time  =  IF  fintime?(tl)  &  fintime?(t2)  THEN  fintime(dur(tl)  +  dur(t2)) 

ELSE  infinity  ENDIF; 

-  (tlitime,  t2:(fintime?)):time  = 

IF  fintime?(tl)  &  dur(tl)  >=  dur(t2)  THEN  fintime(dur(tl)  -  dur(t2)) 
ELSE  infinity  ENDIF; 

END  time_thy _ 


Figure  3:  The  Theory  time_thy  and  the  Data  Type  time. 

Like  many  other  strongly  typed  languages,  the  PVS  specification  language  represents  union  types  using 
abstract  data  type  definitions  reminiscent  of  traditional  algebraic  specifications.  In  PVS,  these  definitions 
consist  of  a  line  for  each  constructor  which  specifies  the  constructor  name,  names  and  types  for  each  ar¬ 
gument  (if  any)  to  the  constructor,  and  a  predicate  that  recognizes  elements  of  the  data  type  built  using 
the  constructor.4  We  thus  define  the  type  time  as  a  PVS  data  type.  (Later,  we  define  another  part  of  our 
template,  the  type  actions ,  as  a  PVS  data  type;  its  definition  is  similarly  understood.) 

The  data  type  time  has  two  constructors.  The  first  constructor,  fintime ,  has  a  non-negative  real  parameter 
dur  and  the  recognizer  fintime ?,  and  the  second  constructor,  infinity ,  has  no  parameters  and  the  recognizer 
inftime?!  The  PVS  prover  recognizes  the  following  assertions  as  true: 

dur{fintime(x))  =  x  (for  any  x  £  R-°) 
fintime?(fintime(x))  (for  any  x  £  R~° ) 
inftime  ?( infinity) 

The  theory  time_thy  contains  the  definitions  of  the  standard  arithmetic  operators  and  predicates  for  time 
values.  Note  that  we  have  exploited  the  support  PVS  provides  for  overloading  names. 

4  A  Template  for  Timed  Automata  Models 

4.1  What  the  Template  Looks  Like 

Figure  4  shows  one  template  we  have  developed  for  defining  a  timed  automata  model  in  PVS.  The  tem¬ 
plate  imports  appropriate  instantiations  of  the  fixed  theories  time_thy,  states,  and  machine.  The  theory 
time.thy  appears  first  in  the  template  because  it  has  no  parameters.  The  two  remaining  theories,  states 
and  machine,  appear  later  in  the  template  because  their  parameters  must  first  be  defined.  The  template 

4When  processing  a  datatype  declaration,  the  PVS  typechecker  generates  individual  declarations  for  all  the  constructors, 
their  arguments,  and  their  recognizers,  together  with  axioms  defining  their  relationships,  an  induction  axiom,  etc. 
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<timed-automaton  name>:  THEORY 
BEGIN 

IMPORTING  time_thy 
actions :  DATATYPE 
BEGIN 

nu(timeof:(fintime?)):  nu? 

<...> 

END  actions; 

MMTstates:  TYPE  =  <...> 

IMPORTING  states[actions,MMTstates,time,fintime?] 

OKstate?  (s: states):  bool  =  <...>; 

enabled_general  (a:actions,  s:states):bool  =  now(s)  >=  first(s)(a)  &  now(s)  <=  last(s)(a); 

enabled_specific  (auctions,  s:states):bool  = 

CASES  a  OF 

nu(delta_t):  (deltaj;  >  zero  &  <...>), 

<...> 

ENDCASES; 

trans  (auctions,  s:states):states  = 

CASES  a  OF 

nu(delta_t):  s  WITH  [now  :=  now(s)+delta_t], 

<...> 

ENDCASES; 

enabled  (auctions,  s:states):bool  = 

enabled_general(a,s)  &  enabled_specific(a,s)  &  OKstate?(trans(a,s)); 

start  (s:states):bool  =  (now(s)  -  zero)  &<...>; 

IMPORTING  machinefstates,  actions,  enabled,  trans,  start] 

END  <timed-automaton  name> 


Figure  4:  A  Template  for  Specifying  Timed  Automata  Models. 


is  instantiated  by  filling  in  the  missing  parts  and  adding  any  desired  auxiliary  declarations  and  definitions. 
The  missing  parts  are  represented  in  Figure  4  by  the  symbol  “<  . . .  >”.5 

Before  the  theory  states  can  be  imported,  two  of  its  parameters,  actions  and  MMTstates ,  must  be 
defined.  The  type  actions  is  defined  as  a  data  type  with  one  constructor,  the  time  passage  action  nu ,  which 
is  an  action  associated  with  every  timed  automata  model.  The  corresponding  parameter  extractor,  called 
timeof ‘  is  declared  as  an  element  of  type  time  that  satisfies  the  predicate  fintime?.  The  symbol  “<  ...  >” 
is  a  placeholder  for  the  other  (non-time-passage)  actions  associated  with  a  given  timed  automaton.  The 
type  of  the  basic  component  of  an  element  of  type  states  is  MMTstates.  The  symbol  “<  . . .  >”  that  follows 
“MMTstates:  TYPE  =”  is  a  place  holder  for  the  nondefault  part  of  the  state  of  the  timed  automaton, 
typically  a  record  structure.  Once  actions  and  MMTstates  are  defined,  the  type  states  can  be  defined  by 
importing  the  appropriate  instance  of  the  theory  states. 

One  proceeds  in  a  similar  fashion  before  importing  the  theory  machine.  The  definition  of  the  predicate 
enabled  divides  naturally  into  three  parts.  The  first  part,  enabled-general ,  is  the  same  for  all  timed  automata; 
it  defines  the  time  bounds  associated  with  actions.  In  particular,  if  the  automaton  is  in  state  s,  its  time 
now(s)  allows  action  a  to  occur  if  it  is  bounded  below  by  first(s)(a)  and  above  by  last(s)(a).  The  second 
part,  called  enabled-specific ,  restricts  the  time  passage  action  nu  to  positive  values  and  provides  place  holders 
for  other  restrictions  on  when  actions  are  enabled  in  a  given  timed  automaton.  The  third  part  is  defined  by 
the  predicate  OKstate?  on  states,  which  provides  an  optional  mechanism  for  enforcing  a  state  invariant  by 
fiat.  In  the  transition  function  trans ,  the  definition  of  “nu(delta_t)”  is  the  same  for  all  timed  automata:  as 
expressed  by  the  WITH  construct,  the  effect  of  a  time  passage  action  is  simply  to  update  the  now  component 

5The  form  of  the  template  to  use,  as  well  as  that  of  the  missing  parts,  depends  on  how  adherence  to  the  template  conventions 
is  enforced.  Section  6  discusses  this  issue.  An  alternate  template  is  presented  in  Appendix  F. 
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of  the  state.6  The  remaining  action  cases  for  a  particular  timed  automaton  must  be  supplied.  Finally,  the 
partial  declaration  of  the  predicate  start(s)  indicates  that  it  must  enforce  the  requirement  now(s)  =  zero . 

We  introduce  an  additional  convention  in  our  timed  automaton  template  to  make  our  proof  strategies 
simpler:  State  invariants  are  assigned  names  of  the  form  Inv.<name>,  and  the  associated  state  invariant 
lemma  (or  theorem)  is  called  lemma„<name>  (or  theorems name>).  The  PVS  proof  of  the  Safety  Property 
in  Section  5  uses  this  convention. 

4.2  Instantiating  the  Template 

To  illustrate  an  instantiation  of  the  template,  we  use  the  template  to  specify  in  PVS  the  timed  automaton 
Trains ,  a  component  of  the  timed  automata  solution  of  the  GRC  problem.  Before  presenting  the  PVS 
specification,  we  present  the  original  specification  of  Trains ,  extracted  from  [13].  The  timed  automaton 
Trains  has  no  input  actions,  three  output  actions,  enterR(r ),  enterl(r ),  and  exit(r ),  for  each  train  r,  and 
the  time  passage  action  The  basic  component  of  each  train’s  state  is  the  status  component,  which 

simply  describes  where  the  train  is.  Each  train’s  state  also  includes  a  current  time  component  now ,  and  first 
and  last  components  for  each  action,  giving  the  earliest  and  latest  times  at  which  an  action  can  occur  once 
enabled. 

The  state  transitions  of  Trains  are  described  by  specifying  the  “Precondition”  under  which  each  action  can 
occur  and  the  “Effect”  of  each  action,  s  denotes  the  state  before  the  event  occurs,  and  s'  the  state  afterwards. 
The  transition  function  contains  conditions  that  enforce  the  bound  assumptions;  that  is,  an  event  cannot 
happen  before  its  first  time,  and  time  cannot  pass  beyond  any  last  time.  In  the  Trains  specification,  only 
the  state  components  now  and  ftrst(enterl(r))  and  last(enterl(r))  for  each  r  contain  nontrivial  information, 
so  the  other  cases  are  ignored.  Note  that  the  time  that  enterl(r)  occurs  is  always  no  sooner  than  and 
no  later  than  e2  after  the  train  r  entered  the  region  P.  The  states  and  transitions  of  the  timed  automaton 
Trains  are  shown  in  Figure  5. 


State: 

now ,  a  nonnegative  real,  initially  0 
for  each  train  r  : 

r.status  e  fnot-here,  P,  1 }>  initially  not-here 
first(enterl(r)),  a  nonnegative  real,  initially  0 
last(enterl(r)),  a  nonnegative  real  or  initially  oo 


Transitions: 
enterR(  r) 

Precondition: 

s.  r.status  =  P 
Effect: 

s'. r.status  =  P 
s'.first(enterl(r ))  =  now  +  z] 
s '.  last(  enterl(  r))  =  now  +  £2 

exit(r) 

Precondition: 

s.  r.status  =  / 

Effect: 

s  '.r.status  ~  not-here 


enterl(r) 

Precondition: 

s.  r.status  =  P 

s.now  >  s.first(enterl( r)) 

Effect: 

s'. r.status  ~  1 
s'.first(enterl(r))  -  0 
s'.last(enterl(r))  =  °o 

v(Af ) 

Precondition: 

for  all  r, 

s.now + At  <  s.last(enterl(r)) 

Effect: 

s'. now  =  s.now  +  At 


Figure  5:  States  and  Transitions  of  the  Timed  Automaton  Trains. 


6The  template  we  present  here  thus  restricts  the  time  passage  action  more  than  does  the  model  we  described  in  Section 
2.2.  Sometimes,  as  in  the  railroad  crossing  solution  with  a  continuous  gate  action  described  in  [12],  one  wants  to  allow  other 
components  of  the  state  besides  the  now  component  to  change  during  time  passage.  An  obvious  modification  of  our  template 
would  permit  our  template  to  support  the  description  of  these  more  general  timed  automata. 
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trains:  THEORY 
BEGIN 

IMPORTING  time.thy 
delta_t:  VAR  (fintime?); 
eps_l,  eps_2:  (fintime?); 
train:  TYPE; 
r:  VAR  train; 
actions  :  DATATYPE 
BEGIN 

nu(timeof: (fintime?)):  nu? 
enterR(Rtrainof:train):  enterR? 
enterI(Itrainof:train):  enterl? 
exit(Etrainof: train):  exit? 

END  actions; 
a:  VAR  actions; 
status:  TYPE  =  {not_here,P,I}; 

MMTstates:  TYPE  =  [train  ->  status]; 

IMPORTING  states  [actions,  MMTstates,  time,  fintime?] 
status(r:train,  s: states): status  =  basic(s)(r); 

OKstate?  (s:states):  bool  =  true  ; 

enabled_general  (auctions,  s: states): bool  =  now(s)  >=  first(s)(a)  &  now(s)  <=  last(s)(a); 
enabled_specific  (auctions,  s:states):bool  = 

CASES  a  OF 

nu(delta__t):  (delta_t  >  zero  &  (FORALL  r:  now(s)  +  delta_t  <=  last(s)(enterl(r)))), 

enterR(r):  statuses)  =  not__here, 

enterl(r):  statuses)  =  P  &  first(s)(a)  <=  now(s), 

exit(r):  statuses)  =  I, 

ENDCASES 

trans  (auctions,  s:states):states  = 

CASES  a  OF 

nu(delta_t):  s  WITH  [now  :=  now(s)+delta„t], 

enterR(r):  (#  basic  :=  basic(s)  WITH  [r  :=  P],  now  :=  now(s), 

first  :=  first(s)  WITH  [(enterl(r))  :=  now(s)+eps„l], 
last  :=  last(s)  WITH  [(enterl(r))  :=  now(s)+eps_2]  #), 
enterl(r):  (#  basic  :=  basic(s)  WITH  [r  :=  I],  now  :=  now(s), 
first  :=  first(s)  WITH  [(enterl(r))  :=  zero], 
last  :=  last(s)  WITH  [(enterl(r))  :=  infinity]  #), 
exit(r):  s  WITH  [basic  :=  basic(s)  WITH  [r  :=  not_here]] 

ENDCASES; 

enabled  (auctions,  s:states):bool  = 

enabled_general(a,s)  &  enabled_specific(a,s)  &  OKstate?(trans(a,s)); 
start  (s:states):bool  =  (s  =  (#  basic  :=  (LAMBDA  r:  not_here),  now  :=  zero, 

first  :=  (LAMBDA  a:  zero),  last  :=  (LAMBDA  a:  infinity)  #)); 
IMPORTING  machine[states,  actions,  enabled,  trans,  start] 

END  trains 


Figure  6:  Instantiating  the  Template  to  Specify  Trains . 


Figure  6  uses  our  template  to  specify  the  Trains  automaton  in  PVS.  In  addition  to  the  time  passage 
action  nu ,  the  instantiation  contains  the  three  output  actions,  enterR(r ),  enterl(r ),  and  exit{r),  for  each 
train  r.  The  basic  component  of  each  train’s  state,  which  has  type  status ,  has  the  value  notJiere ,  P,  or  IJ 
The  predicate  enabled-specific  captures  the  “Preconditions”  and  the  function  trans  captures  the  “Effects” 
shown  in  the  above  specification.  Note  the  lower  and  upper  bounds,  eps-1  and  eps-2,  on  the  action  enterl(r) 
established  by  the  action  enterR  (r).  Also  note  the  initialization  of  the  start  states  with  the  basic  component 
set  to  notJiere ,  the  now  component  to  zero  (thus  fulfilling  the  template  requirement),  and  the  first  and 

7In  this  simple  example,  we  were  able  to  define  the  type  MMTstates  of  the  automaton  basic  state  as  a  simple  function  type, 
rather  than  the  more  typical  record  type  used  in  AxSpec ,  OpSpec ,  and  Systlmpl  (see  Appendix  B). 
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last  components  to  zero  and  infinity,  respectively.  Our  template  instantiation  also  includes  some  auxiliary 
declarations,  such  as  the  types  trains  and  status  needed  to  define  the  type  MMTstates ,  and  the  function 
status{ry  s),  which  retrieves  the  value  of  the  status  component  of  train  r  in  state  s. 


5  Two  Examples  of  Proofs 

To  illustrate  the  correspondence  between  a  hand  proof  and  a  PVS  proof,  this  section  presents  example  hand 
proofs  and  corresponding  PVS  proofs  of  two  results.  The  first  hand  proof  is  a  proof  of  the  induction  principle 
presented  in  Section  3.1.  The  second  is  a  proof  of  the  Safety  Property  taken  from  the  technical  report  [12]. 

5.1  Proof  of  the  Induction  Principle 

The  first  hand  proof  establishes  an  essential  component  of  the  support  we  provide  for  developing  PVS  proofs 
for  timed  automata,  namely,  the  induction  principle.  This  example  illustrates  how  a  very  detailed  hand 
proof  can  be  translated  almost  directly  into  a  PVS  proof.  At  the  same  time,  it  illustrates  the  need  to  bring 
additional  knowledge  to  the  prover  at  points  where  the  hand  proof  implicitly  appeals  to  human  knowledge 
and  experience. 

Figure  7  gives  our  detailed  hand  proof  of  the  induction  principle,  while  Figure  8  presents  our  best  PVS 
approximation  to  that  proof.  A  systematic  method  for  translating  much  of  the  hand  proof  to  the  PVS  proof 
maps  short  proof  steps  to  particular  PVS  rules  or  strategies.  For  example,  to  appeal  to  a  definition,  use 
EXPAND;  to  “suppose”  the  hypotheses  of  an  implication  being  proved,  use  FLATTEN;  to  say  “let  *  • 
or  “choose  •  •  •”,  use  SKOLEM;  to  apply  a  quantified  formula  or  to  establish  one  by  providing  an  instance, 


Step  1. 


Step  2. 
Step  3. 


Step  4. 
Step  5. 
Step  6. 

Step  7. 
Step  7.1. 
Step  7.2. 


What  one  wants  to  prove  is  the  following  formula — call  it  (*): 

V/nv :  states  bool . 

(V5 :  states,  start  (s )  =>  Inv  (s )  a 

Vs :  states ,  a  :  actions :  ( reachable  (s )  a  Inv  (s )  a  enabled  (a ,  s  ) 

=>  Inv  ( trans  ( a ,  s )))) 

=>  Vs :  states,  reachable  (s )  =>  Inv  (s  ) 

Let  Inv ,  be  a  particular  state  invariant.  We  will  show  that  the  body  of  (*)  holds  for 

InV  y 

So,  suppose  that 

(a)  Vs :  states .  start  (s )  =>  Inv  x  (s ) 
and 

(P)  Vs :  states ,  a :  actions :  {reachable  (s )  a  In  v ,  (s  )  a  enabled  (a,  s  ) 

Inv  j  ( trans  ( a ,  s ))). 

Then,  let  s  x  be  a  particular  state.  We  will  show  that  reachable  (s  j)  =>  Inv  j(s  j). 
Thus,  suppose  reachable  (s  j). 

Now,  reachable  (s  {)  means  that  Sj  can  be  reached  from  a  start  state  in  n  steps,  for 
some  n  >  0. 

We  will  use  induction  on  n. 

If  n  =  0,  then  start  (s  j).  In  this  case,  by  (a),  Inv  j(s  j)  holds. 

If  n  >  0,  then  s  j  =  trans  (aQ,s0)  for  some  state  s0  reachable  in  n  — 1  steps  from 
a  start  state  and  some  action  a0  for  which  enabled  (a  0,  s 0)  is  true.  By  induc¬ 
tive  hypothesis,  //iVj(s0)  holds.  By  (P)  applied  to  a0  and  s0 , 
Inv  x{trans  (a q,  s0))  holds;  i.e.,  Inv  ^sj  holds. 

QED. 


Figure  7:  Hand  Proof  of  the  Induction  Principle. 
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Step  1. 

Step  2. 

Step  3. 

Step  4. 

Step  5. 

Step  6. 

Show  induction  result 
is  sufficient. 


r 

(EXPAND  "inductthm") 

(SKOLEM  1  "Inv_l") 

(FLATTEN) 

(SKOLEM  1  ”s_r) 

(FLATTEN) 

(EXPAND  "reachable") 

(CASE  "(FORALL(n): 

(FORALL(s):  (reachable_hidden(s,n)  =>  Inv_l(s))))") 


(Cr 

Let  n_0  be  such  that  (DELETE  -2  -3) 

reachable_hidden(s_  1  ,n_0).  (SKOLEM  -2  "n_0" ) 


Induction  result  applied 
to  s_l  and  n_0 
finishes  the  proof. 

Step  7. 

Begin  Step  7.1. 


(INST-1  "n_0") 
(INST-1  "s_l") 
(GROUND)) 


("2" 

(INDUCT  "n") 


(("!" 

(DELETE  -2  -3  2) 


If  n  =  0  then  start(s__l ).  (EXPAND  "reachable_hidden") 


By  (a),  (EXPAND  "base") 

In  v_l(s_l)  holds.  (PROPAX)) 


Begin  Step  7.2.  ("2" 


Let  j_l  >  0. 

Suppose  ind.  hyp.  for  j_l. 


(DELETE  -1  -3  2) 
(SKOLEM  1  "j_n 
(FLATTEN) 


Choose  s_0 1 ,  and  (S  KOLEM  1  " s_0 1 " ) 

suppose  reachable  in  j_l+l  steps.  (FLATTEN) 


Then  s_01  is  reached  from  s  via  a  (EXPAND  "reachable_hidden"  -2) 
for  some  s  reachable  in  j_l  steps.  (SIMPLIFY) 

Let  a  =  a_0  and  s  =  s_0.  (SKOLEM  -2  ("a_0"  "s„0")) 


By  inductive  hypothesis,  (INST  -1  "s_0") 

lnv_l(s_0)  holds.  (GROUND) 


By  (p) 

applied  to  a_0  and  s_0, 
lnv_l(trans(a_0,s„0))  holds. 


(EXPAND  "inductstep") 
(INST -5  "s_0"  "a JT) 
(GROUND) 


because  s_0  is  reachable  (EXPAND  "reachable") 

in  j_l  steps. _ (INST  1  "LI")))))) 


Figure  8:  PVS  Proof  of  the  Induction  Principle. 

use  INST;  to  do  straightforward  simplification  and  propositional  reasoning,  use  GROUND;  and  to  set  up 
an  induction,  use  INDUCT.  Together  with  a  few  uses  of  DELETE  to  simplify  the  current  proof  goal  and 
one  use  of  SIMPLIFY  to  simplify  an  assertion,  the  set  of  translations  above  is  sufficient  to  handle  nearly 
everything  in  our  hand  proof.8 

The  correspondence  between  the  steps  in  the  hand  proof  and  the  PVS  steps  is  more  easily  understood 
from  the  actual  user  interaction  with  PVS.  Figure  9  shows  the  contents  of  the  PVS  proof  buffer  during  the 
first  few  steps  of  the  proof  in  Figure  8.  The  current  goal  at  each  step  is  represented  as  a  sequent,  with  a  line 
dividing  a  fist  of  hypotheses  from  a  list  of  conclusions.  At  each  step,  the  object  is  to  show  that  at  least  one 

8The  PROPAX  in  Figure  8  is  generated  by  PVS,  and  is  not  supplied  by  the  user. 
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machine_induct : 


{ 1 }  (FORALL  Inv:  inductthm(Inv)) 

Rule?  (EXPAND  "inductthm") 

Expanding  the  definition  of  inductthm,  this  simplifies  to: 
machinejnduct : 

| - 

{ 1 }  (FORALL  Inv:  base(Inv)  &  inductstep(Inv)  =>  (FORALL  (s:  states):  reachable(s)  =>  Inv(s))) 
Rule?  (SKOLEM  1  "InvJ") 

For  the  top  quantifier  in  1,  we  introduce  Skolem  constants:  Inv_l,  this  simplifies  to: 
machine_induct : 

| - 

{ 1 }  base(Inv_l)  &  inductstep(Inv_l)  =>  (FORALL  (s:  states):  reachable(s)  =>  InvJ(s)) 

Rule?  (FLATTEN) 

Applying  disjunctive  simplification  to  flatten  sequent,  this  simplifies  to: 
machine_induct : 

{-1}  base(Inv_l) 

{-2}  inductstep(lnvj) 

| - 

{ 1 }  (FORALL  (s:  states):  reachable(s)  =>  Inv  J(s)) 

Rule?  (SKOLEM  1  "s_l") 

For  the  top  quantifier  in  1,  we  introduce  Skolem  constants:  s_l,  this  simplifies  to: 
machinejnduct : 

[-1]  base(lnvj) 

[-2]  inductstep(Inv„l) 

| - 

{ 1 }  reachable(s_l )  =>  Inv_  1  (s_l ) 

Rule?  (FLATTEN) 

Applying  disjunctive  simplification  to  flatten  sequent,  this  simplifies  to: 
machinejnduct : 

[-1]  base(lnvj) 

[-2]  inductstep(lnvj) 

{ “3 }  reachable(s„  1 ) 


{1)  InvJ(sJ) 

Rule?  (EXPAND  "reachable”) 

Expanding  the  definition  of  reachable,  this  simplifies  to: 
machinejnduct : 

[-1]  base(lnvj) 

[—2]  inductstep(lnvj) 

{-3}  (EXISTS  (n:  nat):  reachable Jiidden(s_l,  n)) 


[1]  InvJ(sJ) 


Figure  9:  Contents  of  the  PVS  Proof  Buffer. 

of  the  conclusions  follows  from  the  hypotheses.  The  sequents  in  Figure  9  all  have  only  one  conclusion. 

The  parts  of  the  hand  proof  in  Figure  7  that  require  the  help  of  a  knowledgeable  human  when  translating 
to  the  PVS  proof  in  Figure  8  are  those  associated  with  induction:  first,  the  specification  of  exactly  what 
to  prove  by  induction;  second,  establishing  that  this  inductive  assertion  is  enough  to  obtain  the  proof;  and 
finally,  replacement  of  the  state  s- 1  in  the  induction  step  Step  7.2  by  an  arbitrary  state  reachable  in  the 
same  number  of  steps. 

To  fully  understand  the  correspondence  between  the  proofs  in  Figures  7  and  8,  one  needs  to  run  PVS. 
For  example,  although  the  specification  of  machine  makes  clear  that  “induct step”  corresponds  to  hypothesis 
(/?),  to  apply  (/?)  to  a_0  and  one  needs  to  know  that  its  assertion  number  is  —5.  The  ability  to  tag 
assertions  or  identify  them  by  content  would  reduce  this  problem. 

In  contrast  to  our  detailed  PVS  proof,  we  show  in  Figure  10  a  more  conventional  PVS  proof  of  the 
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r 

(GRIND  :IF-MATCH  NIL) 

(CASE  "(FOR ALL  (n):  (FORALL  (s):  (reachable_hidden(s,n)  IMPLIES  Inv!l(s))))M) 

(("1"  (GRIND)) 

("2" 

(INDUCT  "n") 

(("1"  (GRIND)) 

("2" 

(GRIND  :IF-MATCH  NIL) 

(APPLY  (THEN  (INST  -8  "si !  1 "  "a!  1 ")  (INST  -2  "si !  1 ")) 

"At  this  point,  it  is  evident  that  we  have  the  inductive  hypothesis  for  n  =  j!  1  and  the 
hypothesis  (beta)  to  work  with,  and  need  to  establish  Inv!l(perform(a!l,sl!l)). 

So,  we  instantiate  the  latter  with  si !  1  and  a!  1,  and  the  former  with  si !  L") 
(GRIND)))))) 


Figure  10:  PVS  Proof  Using  GRIND. 

induction  principle  which  relies  heavily  on  the  workhorse  strategy  GRIND.9  In  this  proof,  one  must  also 
supply  the  inductive  assertion.  In  addition,  one  must  determine  when  to  tell  GRIND  not  to  reduce  quantified 
formulae  (the  effect  of  the  “:IF-MATCH  NIL”  argument),  and  help  PVS  decide  how  to  use  the  inductive 
hypothesis  and  assumption  (/3).  One  must  also  analyze  the  current  goal  after  a  call  to  GRIND  terminates 
to  recognize  what  help  is  needed. 

We  refer  to  these  two  styles  of  PVS  proofs  as  small  step  and  large  step  proofs.  One  can  view  a  hand 
proof  as  a  proof  plan  for  a  PVS  proof.  With  a  small  step  proof,  one  can  more  easily  determine  what  point 
has  been  reached  in  a  proof  plan  and  what  step  one  wishes  to  take  next.  With  a  large  step  proof,  especially 
one  using  generic  large  steps  based  on  GRIND,  it  is  harder  to  control  the  position  in  the  proof  plan.  In  fact, 
in  some  cases,  this  position  may  not  be  well  defined,  since  GRIND  may  perform  steps  from  the  plan  out  of 
order.  With  experience,  a  PVS  user  can  often  predict  the  result  of  a  large  step,  but  even  so  must  rely  on 
interaction  with  PVS  to  see  just  what  piece  of  information  from  the  plan  should  be  provided  to  PVS  next. 

In  our  experience,  both  styles  of  proof  benefit,  in  terms  of  speed  of  construction  with  minimal  back¬ 
tracking,  from  the  existence  of  a  proof  plan.  We  note  that  if  the  automatic-instantiation  feature  of  GRIND 
had  been  somewhat  more  powerful,  the  only  proof  information  PVS  would  have  required  in  the  large  step 
proof  is  the  inductive  assertion,  and  the  reason  why  the  resulting  PVS  proof  worked  would  be  impossible  to 
discern.10  The  degree  to  which  we  find  the  resulting  PVS  proof  convincing,  in  the  sense  that  the  theorem 
is  true  for  the  right  reasons,  is  certainly  greater  with  the  small  step  proof,  although  some  of  these  reasons 
were  supplied  to  PVS  in  the  large  step  proof. 

On  the  other  hand,  for  theorems  with  complex  proofs,  or  for  theorems  with  proofs  having  a  standard 
structure,  mimicking  all  the  micro-steps  of  the  PVS  proof  is  unnecessarily  tedious  and  repetitive.  In  our 
specialized  domain,  we  have  been  able  to  define  reusable  PVS  strategies  that  allow  the  user  to  follow  a  proof 
plan  reasonably  closely  without  most  of  the  tedium  of  providing  the  micro-steps.  Large  step  proofs  using 
GRIND  typically  execute  several  times  as  slowly  as  short  step  proofs.  Because  our  strategies  are  specialized 
for  timed  automata,  they  yield  an  efficiency  comparable  to  that  of  short  step  proofs. 

5.2  Proof  of  the  Safety  Property 

Our  second  example  of  a  hand  proof  translated  into  a  PVS  proof  is  a  proof  with  a  standard  structure: 
namely,  the  proof  by  induction  of  a  state  invariant.  The  particular  state  invariant  is  the  Safety  Property  for 
the  timed  automaton  Systlmpl ,  which  is  stated  and  proved  as  Lemma  6.3  in  [12,  13].  Figure  11  shows  the 
hand  proof  and  the  corresponding  PVS  proof. 

The  PVS  proof  uses  the  induction  strategy  AUTOJPROOF_UNIV-.SYSTIMPL  to  set  up  the  induction, 

9The  GRIND  strategy  in  PVS  approximates  an  automatic  theorem  prover.  It  expands  definitions  and  forms,  applies  rewrites, 
invokes  propositional  and  arithmetic  decision  procedures,  and  does  automatic  skolemization  and  instantiation.  Instantiation  is 
done  by  best  guess  and  can  be  incorrect.  To  provide  more  control  of  instantiation  and  other  features,  GRIND  has  options  that 
can  be  selected  by  supplying  arguments. 

10If  one  uses  GRINDS  in  place  of  GRIND,  PVS  will  save  the  small  steps  that  GRIND  has  followed.  However,  understanding 
these  steps  is  very  difficult. 
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Lemma  6.3.  In  all  reachable  states  ofSystlmpl,  if  Trains,  r.  status  =  I  for  any  r,  then  Gate.status  =  down. 
Proof:  Use  induction.  The  interesting  cases  are  enterl  and  raise .  Fix  r. 

1.  enterl  (r) 

By  the  precondition,  s.Trains.r.status  =P . 

If  s.Gate. status  e  { up, going -up  },  then  Lemma  6.1  implies  that  s.Trains.f  irst  (enterl  (r))  > 
now  +  Yifowit*  so  s.Trains.f  irst  (enterl  (r))  >  now.  But,  the  precondition  for  enterl  (r)  is 
s.Trains.f  irst  (enterl (r))  <  now .  This  means  that  it  is  impossible  for  this  action  to  occur,  a  contradic¬ 
tion. 

If  s.Gate.status  =  going -down ,  then  Lemma  6.2  implies  that  s.Trains.f  irst  (enterl  (r))  > 
s.Gate.last(down).  By  Lemma  B.l,  s.Gate.status  =  going -down  implies  s.Gate.  last  (down)  >  now. 
This  implies  that  s.Trains.f irst  (enterl  (r))  >  now,  which  again  means  that  it  is  impossible  for  this 
action  to  occur. 

The  only  remaining  case  is  s.Gate.status  =  down.  This  implies  s  '.Gate.status  =  down,  which  suffices. 

2.  raise 

We  need  to  show  that  the  gate  doesn’t  get  raised  when  a  train  is  in  /.  So  suppose  that  s.Trains.r.status 
-  I .  The  precondition  of  raise  states  that  3r:  s.CompImpl.r.sched-time  <  now  +  y  +  5  + 
which  implies  that,  for  all  r,  s.CompImpl.r.sched-time  >  now .  But  Parts  1  and  3  of  Lemma  5.1  imply 
that  in  this  case,  s.Trains.r.status  =  P ,  a  contradiction. 

Inv_6_3_A(s:  states):bool  =  (  FORALL  (r:  train):  status(r,s)  =  I  =>  gate_status(s)  =  fully_down  ); 

(""  (APPLY  (AUTO_PROOF_UNIV_SYSTIMPL  "Inv_6_3_A")  "Use  induction.  Fix  r  =  r_2.") 

(("1"  (APPLY  (THEN  (EXPAND  "enabled.specific")  (SYSTIMPL_SIMP)) 

"Case  enterl(r_l).  Invoke  the  precondition.") 

(CASE  "gate_status(s_l)  =  fully_up  OR  gate_status(s_l)  =  going_up") 

(("1"  (APPLY  (THEN  (APPLY_UNIV_INV_LEMMA  "6J"  "r_l")  (SYSTIMPL_SIMP)) 
"Invoke  the  invariant  lemma  6_1.") 

(APPLY  (TIME__ETC_SIMP)  "Derive  contradiction  with  the  precondition.")) 

("2"  (APPLY  (THEN  (APPLY_UNIV_INV_LEMMA  "6_2"  "r_l")  (SYSTIMPL_SIMP)) 
"Invoke  the  invariant  lemma  6_2.”) 

(APPLY  (THEN  (APPLY JNV_LEMMA  "B_l_l")  (SYSTIMPL_SIMP)) 

"Invoke  invariant  lemma  B_l,  part  1.") 

(APPLY  (TIME_ETC_SIMP)  "Derive  contradiction  with  the  precondition.")))) 

("2"  (APPLY  (THEN  (EXPAND  "enabled_specific")  (SYSTIMPL_SIMP)  (INST  2  "r_2")) 

"Case  raise.  Invoke  and  specialize  the  precondition.") 

(APPLY  (THEN  (APPLY_UNIV_INV_LEMMA  "5_1_1"  "r_2")  (SYSTIMPL_SIMP)) 

"Invoke  invariant  lemma  5_1,  part  1.") 

(APPLY  (THEN  (APPLY_UNIV_INV_LEMMA  "5_1_3"  "r_2")  (SYSTIMPL_SIMP)) 

"Invoke  invariant  lemma  5_1,  part  3.") 

(APPLY  (TIME_ETC_SIMP)  "Derive  contradiction.")) 

("3"  (APPLY  (THEN  (EXPAND  "enabled_specific")  (SYSTIMPL_SIMP)) 

_ "Case  up.  Invoke  the  precondition.")))) _ 


Figure  11:  Hand  Proof  and  PVS  Proof  of  the  Safety  Property. 

potentially  producing  subgoals  for  the  base  case  and  each  possible  action.  Subgoals  deemed  sufficiently 
“trivial”  are  proved  automatically,  and  only  the  nontrivial  subgoals  are  displayed.  As  can  be  seen,  in  the 
hand  proof,  the  action  cases  for  enterl(r)  and  raise  are  the  nontrivial  cases.  The  PVS  proof  of  the  enterl(r) 
case  is  obtained  as  in  the  hand  proof  by  invoking  the  precondition,  doing  a  case  split,  applying  the  indicated 
lemmas  appropriately,  and  asking  for  a  little  simplification  and  linear  arithmetic.  The  PVS  proof  of  the  raise 
case  is  translated  analogously.  An  extra  case  up  is  generated  in  the  PVS  proof,  but  is  handled  by  invoking 
the  precondition,  a  step  considered  obvious  in  the  hand  proof. 

In  our  general  experience  with  proofs  of  state  invariants,  we  have  noticed  that  an  “extra”  case  waved 
away  as  obvious  in  the  hand  proof  occasionally  turns  up  in  the  PVS  proof.  Appealing  to  one  of  a  short  list 
of  standard  facts  about  timed  automata  typically  proves  these  cases.  In  proving  the  Safety  Property,  the 
standard  fact  needed  is  that  the  precondition  must  be  satisfied  or  the  case  will  not  arise.  The  precondition 
is  present  among  the  hypotheses  in  name,  but  its  definition  must  be  expanded  for  it  to  be  taken  into 
account.  One  other  standard  fact  has  sometimes  been  required  in  handling  the  “obvious”  cases  of  the 
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hand  proofs  we  have  translated  from  [12]:  the  uniqueness  of  actions.  In  particular,  if  r.l  r.2,  then 
enterl(r.l)  ±  enterl(rJJ),  and  similarly  for  other  actions  with  arguments.  One  can  envision  that  certain 
relationships  among  constants  used  to  define  a  timed  automaton  might  also  sometimes  be  considered  too 
obvious  to  mention.  Adding  knowledge  of  such  standard  facts  to  the  induction  strategies  would  eliminate 
the  need  to  deal  with  most  such  “obvious”  cases  interactively,  but  at  the  expense  of  longer  proof  times.  It 
would  also  obscure  their  application  in  the  PVS  proof  in  cases  in  which  one  wants  to  explicitly  mention  them 
in  the  hand  proof  for  emphasis. 

A  close  look  at  the  PVS  proof  of  the  Safety  Property  in  Figure  11  reveals  a  few  subtleties  involving  the 
choice  of  a  particular  version  of  a  strategy  or  its  arguments.11 

With  respect  to  the  choice  of  arguments,  one  notes  first  that  when  an  invariant  lemma  is  invoked,  it  is 
sometimes  applied  to  n ,  and  sometimes  to  r2.  It  would  seem  that  the  choice  of  appropriate  argument  would 
have  to  be  made  by  examining  the  current  PVS  goal.  Although  this  could  be  done,  the  choice  can  be  made 
on  another  basis:  choose  ri  when  one  is  clearly  referring  to  the  train  index  of  the  action  case;  choose  r2  when 
one  is  clearly  referring  to  the  train  whose  status  is  /  (or,  more  generically,  to  the  train  mentioned  explicitly 
in  the  body  of  the  lemma).  Second,  we  note  that  the  precondition  of  raise  is  “specialized”  when  it  is  invoked 
in  the  raise  branch  of  the  proof.  This  is  necessary  because  it  contains  a  quantifier.  The  instantiation  to  give 
that  quantifier  is  r2,  since  the  raise  action  is  not  indexed  over  trains.  This  instantiation  can  also  be  chosen 
based  on  matching  the  body  of  the  quantified  formula  to  the  known  fact  that  r2  is  the  train  whose  status 
is  I.  Thus,  these  choices  of  argument  can  be  made,  if  not  automatically,  at  least  from  information  provided 
by  the  user  of  a  more  abstract  nature  than  the  argument’s  explicit  name. 

With  respect  to  versions  of  strategies,  one  question  that  arises  with  respect  to  the  PVS  proof  in  Fig¬ 
ure  11  is  how  one  chooses  the  particular  induction,  simplification,  and  lemma  application  strategies  used. 
The  choice  of  AUTO-PROOF.UNIV-SYSTIMPL  and  SYSTIMPL_SIMP  can  be  made  by  the  PVS  user  on 
knowing  that  one  is  proving  a  universally  quantified  invariant  in  the  theory  Systlmpl.  Whether  to  use  AP- 
PLY-UNTV  TNV  T.F.MMA  or  APPLY JNVXEMMA  is  determined  by  whether  or  not  the  invariant  lemma  is 
universally  quantified.  We  note  that  while  the  user  can  make  these  choices  of  strategy,  all  of  them  could  be 
made  automatically  by  an  interface  to  PVS,  given  user  input  of  the  form  “use  induction”  or  “apply  invariant 
lemma  6.1”. 

Thus,  in  proving  the  Safety  Property,  it  is  possible  to  shield  the  verifier  from  low-level  interaction  with 
PVS.  Our  experience  so  far  with  other  state  invariant  proofs  indicates  that  this  is  very  often  the  case. 

A  third  category  of  translations  of  hand  proofs  to  PVS  proofs  contains  translations  of  proofs  with  a  more 
ad  hoc  proof  structure  than  state  invariant  proofs.  For  more  ad  hoc  proofs,  our  results  so  far  suggest  that 
one  cannot  disengage  the  verifier  from  low-level  interaction  with  PVS  to  the  extent  that  one  can  with  the 
more  structured  state  invariant  proofs.  However,  one  can  identify  repeated  patterns  of  reasoning  that  occur 
because  a  result  from  a  particular  domain  with  much  shared  structure  is  being  proved.  Appropriate  PVS 
strategies  can  frequently  handle  these  repeated  patterns.  A  menu  of  such  strategies,  specially  tailored  for 
timed  automata  models,  can  support  translating  hand  proofs  into  PVS  proofs  made  up  of  a  combination  of 
a  limited  set  of  small  PVS  steps  combined  with  large  standard  steps,  whose  correspondence  with  the  source 
hand  proofs  is  much  easier  to  see. 

6  Summary  of  Results 

Based  on  our  experience  to  date,  we  discuss  below  our  use  of  template  specifications,  how  repeating  patterns 
in  proofs  were  detected  and  exploited,  how  best  to  interact  with  the  theorem  prover,  and  how  real-time 
properties  are  expressed  and  proven  in  our  approach. 

6.1  Using  Template  Specifications 

Using  a  template  to  create  a  formal  specification  of  a  particular  mathematical  model  greatly  reduces  the 
required  effort.  This  reduction  comes  from  two  sources.  First,  with  the  basic  theories  and  lemmas  already 
specified,  the  amount  that  remains  to  be  specified  for  a  particular  model  is  significantly  reduced.  Second, 
the  existence  of  conventions  regarding  names,  types,  and  definitions  of  the  missing  parts  eliminates  many 

11The  PVS  proof  commands  are  embedded  in  APPLY  so  that  they  can  be  accompanied  by  comments. 
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organizational  decisions  required  in  specifying  a  particular  model:  the  specifier  needs  only  to  fill  in  the 
missing  pieces. 

Creating  a  template  helped  us  to  identify  commonalities  among  instances  of  the  timed  automata  model 
that  can  be  exploited  in  designing  specialized  support  for  proving  properties.  The  very  discipline  of  creating  a 
template  helps  one  to  identify  high  level  common  patterns.  For  example,  in  our  study,  we  identified  induction 
structured  over  actions  as  an  important  principle  that  underlies  many  proofs  about  timed  automata  models. 
This  principle  can  be  used  to  prove  state  invariants  about  these  models  by  invoking  appropriately  designed 
PVS  strategies.  At  a  more  detailed  level,  the  particular  specification  structure  and  conventions  enforced  in 
a  template  can  be  taken  advantage  of  in  creating  reusable  proof  strategies:  for  example,  in  our  template, 
we  know  that  we  always  want  to  expand  the  definition  “start”  of  the  start  state  in  doing  the  base  case  of 
an  induction  proof.  This  advantage  can  be  taken  even  farther  by  exploiting  even  lower  level  features  of  the 
template  such  as  definition  structure.  More  detail  on  the  relation  between  our  template  and  the  strategies 
we  have  developed  can  be  found  in  Appendix  C. 

Templates  can  be  enforced  in  different  ways,  with  tradeoffs  involved.  Through  an  additional,  top-level 
parameterized  theory  added  to  the  framework  in  Section  4,  we  can  require  that  all  models  include  a  time 
passage  action,  define  the  types  of  enabled- specific  and  trans ,  define  the  significance  of  these  three  operators 
in  relation  to  the  admissible  timed  executions  of  a  timed  automaton,  and  enforce  other  similar  template 
conventions.  This  approach  has  the  advantage  of  permitting  many  generic  lemmas  that  provide  important 
support  for  proof  strategies  specialized  for  timed  automata  to  be  proved  without  instantiating  the  template. 
These  generic  lemmas  can  then  be  kept  in  a  standard  library,  saving  much  of  the  processing  time  needed  to 
load  instantiations  of  the  template  into  PVS.  An  alternative  is  to  enforce  the  template  conventions  through 
an  interface  that  compiles  user-provided  information  into  a  PVS  specification  of  the  proper  form.  Our 
experiments  with  template  instantiations  suggest  that  proofs  of  properties  run  more  efficiently  when  the 
second  approach  is  used. 

However,  no  matter  how  the  template  is  enforced,  the  strong  type  system  in  PVS  is  very  helpful  in 
establishing  a  template  discipline.  In  contrast  to  Lamport  [20],  we  find  strong  typing  more  a  help  than  a 
hindrance. 


6.2  Repeated  Patterns  in  Timed  Automaton  Proofs 

In  analyzing  proofs  in  the  timed  automata  domain,  our  approach  has  been  to  create  small  step  proofs, 
optimize  them  for  both  efficiency  and  logical  structure,  and  find  patterns  that  can  be  translated  into  PVS 
strategies.  We  have  found  a  variety  of  patterns.  These  patterns  can  be  classified  by  whether  it  is  possible 
to  translate  them  into  an  appropriate  strategy,  whether  the  strategy  can  be  written  in  PVS  as  it  stands 
or  requires  enhancements  to  PVS,  and  whether  the  strategy  requires  instance-specific  details  to  compile  or 
choose.  The  classification  of  certain  repeating  patterns  remains  to  be  decided.  For  some  patterns,  we  do  not 
yet  have,  a  PVS  strategy  but  can  supply  a  heuristic:  an  example  is  the  recurring  argument  in  hand  proofs 
that  time  cannot  pass  beyond  a  certain  bound  unless  a  certain  type  of  event  occurs.  In  following  a  hand 
proof,  the  need  to  turn  to  a  heuristic  can  arise  when  the  hand  proof  does  not  supply  enough  detail. 

Many  patterns  that  recur  in  small  step  proofs  are  of  such  a  general  nature  that  existing  PVS  strategies 
already  handle  them.  A  simple  example  is  the  pattern  handled  by  the  PVS  strategy  SKOSIMP,  which 
corresponds  to  “Suppose  that  the  hypotheses  hold  for  some  generic  values;  we  will  prove  that  the  conclusion 
holds  for  these  values.”  However,  there  are  some  patterns  of  a  general  nature  that  require  domain  specialized 
PVS  strategies.  An  example  is  the  repeated  need  to  substitute  names  for  values  (as  opposed  to  expressions — 
that  is,  semantically  as  opposed  to  syntactically),  and,  conversely,  to  retrieve  information  associated  with 
names.  Although  this  need  in  general  will  arise  in  nearly  any  domain,  appropriate  strategy  support  will 
require  such  domain-specific  information  as  when  two  expressions  represent  the  same  value,  what  kind  of 
information  there  exists  to  retrieve,  and  so  on.  We  have  made  some  progress  in  writing  PVS  strategies  that 
partially  meet  these  needs;  see  Appendix  C.  Ideal  strategy  support  will  require  certain  enhancements  to 
PVS,  such  as  the  ability  to  recognize  formulae  by  content. 

Others  patterns  have  appeared  that  are  specific  to  timed  automata.  Examples  are  the  repeated  need  to 
apply  state  invariant  lemmas  and  to  establish  that  a  state  is  reachable.  In  Appendix  C,  we  present  strategies 
we  have  defined  to  help  with  each  of  these  patterns.  For  applying  state  invariants,  we  have  two  strategies,  one 
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for  unquantified  invariants  and  another  for  universally  quantified  invariants.  The  choice  of  which  strategy 
to  invoke  is  assumed  to  be  made  externally  to  PVS.  In  principle,  the  choice  could  be  made  internally  by 
PVS  if  more  access  to  the  PVS  data  structures  were  provided.  To  show  that  a  state  in  an  admissible  timed 
execution  is  reachable,  we  have  a  strategy  that  applies  a  lemma  containing  general  reachability  results.  The 
user  must  supply  instantiations  that  focus  the  general  results  on  the  neighborhood  (in  terms  of  the  number 
of  non-time  steps  that  have  occurred)  of  the  state  that  is  to  be  confirmed  to  be  reachable.  With  appropriate 
enhancements  to  PVS,  the  appropriate  instantiations  could  be  inferred  automatically  from  the  current  proof 
goal;  also,  after  simplification  of  the  results  from  application  of  the  lemma,  the  irrelevant  results  could  be 
deleted.  This  is  a  further  example  where  a  better  PVS  strategy  is  in  principle  feasible,  but  not  yet  expressible: 
helpful  enhancements  to  PVS  would  again  include  the  ability  to  recognize  formulae  by  content,  and  also  the 
ability  to  extract  parts  of  formulae  and  to  apply  naming  conventions  to  formulae. 

There  are  other  patterns  specific  to  timed  automata  that  require  instantiation-specific  knowledge  before 
an  appropriate  PVS  strategy  can  be  constructed.  An  important  example  is  in  the  setting  up  cases  in  an 
induction  proof.  Each  case  of  a  particular  form  is  handled  in  a  particular  way.  The  information  that  must 
be  supplied  includes  whether  the  case  is  the  base  case  or  an  action  case;  if  an  action  case,  how  the  action 
is  parameterized;  and  if  an  action  case,  whether  the  body  of  the  corresponding  case  in  the  definition  of 
trans  is  an  IF.THENJELSE.  All  of  the  supplied  information  can  be  determined  automatically  from  the 
instantiated  template  specification.  Thus,  it  is  possible,  in  principle,  to  compile  such  strategies  from  a 
template  instantiation.  It  is  conceivable  that  the  necessary  choices  could  be  made  by  a  single  PVS  strategy 
that  accesses  details  of  definitions;  such  a  strategy  would  require  access  to  the  PVS  data  structures  that 
currently  has  not  been  provided.  There  is  clearly  an  efficiency  tradeoff  involved  in  the  choice  of  solution;  a 
strategy  which  itself  must  make  choices  will  obviously  be  less  efficient.  Whether  the  reduction  in  efficiency 
is  significant  remains  to  be  determined. 

In  proving  state  invariants,  another  interesting  pattern  arises.  In  particular,  when  the  state  invariant 
involves  quantification,  one  often  wishes  to  coordinate  the  simplification  of  the  quantified  formulae  from  the 
inductive  hypothesis  and  conclusion  (specifically,  one  wants  to  instantiate  one  with  the  skolem  constant  or 
constants  from  the  other).  This  is  typically  the  case  when  one  is  reasoning  about  the  behavior  of  independent 
entities,  such  as  the  trains  in  the  GRC  benchmark.  When  this  is  the  case,  the  standard  part  of  the  induction 
strategy  can  be  extended  to  include  this;  this  was  in  fact  done  in  our  proof  of  the  Safety  Property.  The 
fact  that  a  PVS  strategy  could  be  developed  to  do  the  coordination  of  skolemization  and  instantiation 
depended  heavily  on  the  predictability  of  the  assertion  numbers  of  the  related  quantified  formulae.  For 
invariants  involving  quantification  in  other  forms,  such  as  existential  or  embedded,  it  is  harder  to  predict 
the  related  assertion  numbers.  In  principle,  it  should  be  possible  to  extend  the  standard  induction  strategy 
to  handle  any  particular  additional  coordination  case  analogously,  and  also  to  select  the  appropriate  variant 
of  the  induction  strategy  to  apply  automatically  from  knowledge  of  the  form  of  the  invariant  to  be  proved. 
Implementing  such  extensions  would  require  enhancements  to  PVS. 

Some  repeating  patterns  that  occur  in  proofs  are  of  such  a  general  nature  that  the  best  one  can  offer  as 
a  general  solution  is  a  heuristic.  For  these  cases,  one  can  hope  to  provide  automated  support  that  guides 
the  user  in  applying  the  heuristic. 


6.3  Repeated  Patterns  in  Using  PVS 

As  indicated  above,  our  approach  to  PVS  proofs  about  timed  automata  is  to  follow  a  hand  proof  as  closely 
as  possible.  For  nontrivial  theorems,  a  hand  proof  provides  essential  guidance  in  constructing  the  automated 
proof,  since  it  presents,  in  some  organized  fashion,  the  reasons  why  a  theorem  is  believed  to  be  true.  These 
reasons  generally  correspond  closely  to  the  information  that  must  be  supplied  to  a  theorem  prover. 

As  illustrated  in  Section  5,  very  detailed  proofs  and  routine  proofs  can  be  easily  translated  into  PVS.  A 
direct  translation  of  a  detailed  hand  proof  to  a  PVS  proof  involves  detailed  human  guidance,  but  most  of 
this  guidance  is  routine  and  could  conceivably  be  mechanized.  Undertaking  such  a  direct  translation  helps 
to  clarify  at  which  points  in  the  proof  crucial  information  that  involves  some  human  insight  must  be  supplied 
to  the  prover:  e.g.,  in  our  example  proof  of  the  induction  principle,  this  crucial  information  involved  the 
exact  formulation  and  use  of  what  needs  to  be  proved  using  induction  over  natural  numbers.  In  translating 
a  hand  proof  with  a  routine  structure  (e.g.,  an  induction  proof  of  a  state  invariant  of  an  automaton  with 
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a  standard  structure),  human  guidance  is  mostly  needed  to  provide  the  non-routine  facts  and  case  splits 
needed  to  complete  proof  branches  generated  by  a  strategy  that  performs  the  standard  initial  stages  of  the 
proof.  The  need  for  human  guidance  can  be  further  minimized  in  this  case  by  taking  advantage  of  template 
conventions  to  provide  domain-specific  strategies  for  recurring  types  of  reasoning.  For  example,  in  proving 
the  Safety  Property  in  section  5,  the  strategy  TIME_ETC_SIMP  handles  reasoning  about  extended  time 
values. 

Translating  hand  proofs  that  omit  many  details  and  have  an  ad  hoc  structure  to  PVS  requires  signif¬ 
icant  interactive  guidance.  However,  this  problem  can  be  reduced  by  using  domain-specific  strategies  and 
heuristics.  The  domain-specific  strategies  permit  one  to  take  larger  steps  in  a  proof  and  make  it  easier  to 
track  one’s  place  in  the  hand  proof.  An  example  that  has  arisen  in  ad  hoc  proofs  about  timed  automata 
is  the  need  to  confirm  with  minimum  effort  that  a  certain  state  is  reachable,  because  one  wants  to  apply 
a  state  invariant  lemma  to  it.  We  have  designed  a  strategy  that  simplifies  this  step  greatly,  and  would  be 
able  to  improve  it  further  if  certain  enhancements  are  made  to  PVS.  The  specialized  strategies  that  we  have 
developed  so  far  for  ad  hoc  proofs  have  not  reduced  proof  efficiency.  A  preliminary  exercise  in  developing 
domain-specific  strategies  for  timed  automata  and  employing  them  in  an  ad  hoc  proof  resulted  in  a  more 
than  60%  reduction  in  proof  size  (415  lines  to  158  lines)  with  no  penalty — in  fact,  a  slight  improvement — in 
the  running  time  of  the  proof. 

To  keep  track  of  the  correspondence  between  a  hand  proof  and  a  PVS  proof,  inserting  comments  in  the 
PVS  proof  is  very  helpful,  and  for  a  proof  of  any  length,  it  is  essential.  A  combination  of  comments  in 
the  proof  and  a  glossary  of  English  meanings  of  PVS  strategies  can  create  confidence  that  the  PVS  proof 
succeeded  for  the  right  reasons. 

We  have  undertaken  the  translation  into  PVS  of  several  hand  proofs  of  properties  of  timed  automata  of 
an  ad  hoc  structure,  the  longest  being  the  one  page  hand  proof  of  a  result  equivalent  to  the  Utility  Property 
in  Section  2  for  the  timed  automaton  OpSpec.  From  this  experience,  we  can  make  additional  observations 
on  the  process  of  translating  hand  proofs  into  PVS. 

The  first  observation  is  that  although  PVS  has  many  built-in  rules  and  strategies  that  allow  one  to  closely 
mimic  the  steps  of  a  detailed  hand  proof,  there  are  some  cases  in  which  one  cannot  quite  do  this  with  PVS 
as  it  stands.  This  is  not  only  due  to  the  fact  that  one  must  sometimes  take  many  steps  in  PVS  to  follow 
a  step  in  the  hand  proof — a  phenomenon  that  will  become  less  of  a  problem  as  more  specialized  strategies 
are  developed — but  results  from  PVS  sometimes  forcing  a  slightly  different  structure  on  the  proof  by  way  of 
undesired  case  splits. 

In  general,  case  splits  should  be  avoided  unless  they  are  natural  occurrences  in  a  human  style  proof,  since 
when  they  are  forced,  the  existing  proof  plan  will  need  to  be  revised.  A  major  example  where  one  is  forced 
in  PVS  to  split  a  goal  into  separate  subgoals,  where  conceptually  this  is  not  necessary,  is  as  follows.  When 
one  has  facts  A  and  A  =>  B  in  the  antecedent  of  the  goal,  a  call  to  the  PVS  strategy  ASSERT  will,  in  most 
cases,  reduce  the  second  fact  to  simply  B ,  provided  the  form  of  A  is  simple.  For  the  case  when  A  is  more 
complex,  a  user-defined  PVS  strategy  can  be  written  that  will,  in  most  cases,  accomplish  the  same  thing. 
An  exception  in  both  cases  is  when  the  form  of  B  is  B\  =>  B2.  In  this  case,  one  is  forced  into  a  case  split. 
The  difficulty  is  that  some  of  the  PVS  rules  and  strategies  are  not  exactly  on  target  with  the  natural  steps 
in  a  hand  proof.  Adding  rules  to  PVS  that  provide  finer  control  of  subgoal  manipulation  should  overcome 
this  difficulty. 

Even  when  case  splits  are  part  of  the  proof  plan,  they  can  cause  the  problem  of  losing  track  of  one’s  place 
in  a  proof  when  using  PVS.  Planned  case  splits  may  be  explicit  in  the  hand  proof,  or  implicit  as  the  result 
of  including  an  in-line  lemma  in  the  proof — that  is,  a  lemma  proved  on  the  spot  and  then  applied.  After 
doing  several  case  splits  in  a  row  and  then  discharging  subgoals  in  the  default  order,  upon  returning  to  the 
subgoal  or  subgoals  that  correspond  to  the  second  or  additional  branches  from  the  first  case  split,  one  can 
easily  forget  where  they  came  from,  and  therefore,  what  one’s  approach  to  their  proof  will  be.  The  ability  to 
attach  comments  to  related  subgoals  at  least  semi-automatically,  based  on  user  input,  would  greatly  alleviate 
this  problem. 

The  second  observation  is  that  a  very  common  occurrence  in  the  process  of  creating  a  machine-checked 
proof  is  the  reappearance  of  subgoals  that  have  already  been  proved  in  an  earlier  proof  branch.  In  the  hand 
proof,  one  can  simply  say  “as  shown  earlier  ...”  but  this  will  not  work  in  PVS  or  most  other  automatic 
theorem  proving  systems.  However,  one  of  the  advantages  to  starting  from  a  hand  proof  is  the  ability  to  see 
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easily  where  some  piece  of  information  is  used  more  than  once  in  the  proof.  A  careful  restructuring  of  the 
hand  proof  prior  to  undertaking  the  PVS  proof  can  eliminate  much  subgoal  duplication  in  the  PVS  proof, 
particularly  of  subgoals  corresponding  to  facts  playing  a  major  role  in  the  proof.  Our  experience  has  shown 
that  eliminating  all  duplication  of  subgoals  is  difficult  and  perhaps  impossible,  since  some  subgoals  come  from 
type  correctness  conditions  implicitly  needed  for  the  application  of  lemmas  in  the  course  of  the  proof.  And 
even  though  some  repeated  subgoals  can  be  eliminated  by  restructuring  the  proof  plan,  there  will  be  some 
proofs  where  this  can  make  the  reasoning  in  the  proof  more  difficult  to  follow,  since  such  restructuring  usually 
involves  the  up  front  introduction  of  facts  that  will  be  used  more  than  once  whose  role  in  the  proof  is  not 
yet  clear.  Introducing  these  facts  as  separately  proved  lemmas  is  one  possible  solution,  but  not  always  ideal; 
assuming  that  one  is  checking  hand  proofs  using  PVS,  one  must  ask  why  these  facts  were  not  introduced 
as  separate  lemmas  in  the  hand  proof.  The  answer  is  typically  that  they  are  too  specialized  to  be  worth 
including  in  a  theory,  being  unlikely  to  be  used  outside  the  current  proof.  Thus,  some  mechanism  in  PVS 
for  handling  repeating  subgoals  would  be  a  very  welcome  enhancement. 

6.4  Expressing  and  Proving  Real-Time  Properties 

In  our  approach,  the  real-time  properties  of  a  timed  automaton  are  determined  by  the  definitions  of  enabled 
and  trans.  Real-time  properties  that  are  state  invariants  are  proved  in  PVS  by  induction.  The  specific  stage 
at  which  reasoning  about  time  occurs  in  each  branch  of  the  induction  is  typically  a  point  at  which  a  set  of 
inequalities  involving  time  values  has  been  established  by  invoking  the  definitions  of  enabled  and  trans  and 
by  introducing  previous  state  invariant  lemmas.  The  proof  is  then  completed  using  only  reasoning  about  the 
inequalities.  If  time  were  simply  represented  by  the  non-negative  real  numbers,  the  decision  procedures  in 
PVS  that  do  arithmetic  would  complete  the  proof  in  a  single  step.  Because  we  include  infinity  in  the  set  of 
possible  time  values,  these  decision  procedures  will  not  work  directly.  To  handle  this  problem,  we  developed 
a  strategy  called  TIME JETC-SIMP  that  reduces  time  inequalities  to  inequalities  involving  non-negative  real 
numbers  and  then  invokes  the  PVS  decision  procedures  for  arithmetic. 

Care  must  be  taken  in  translating  assertions  involving  time  values  from  hand  proofs  into  PVS.  While 
“negative”  time  values  can  be  used  in  hand  proofs,  they  cannot  be  used  in  our  PVS  proofs,  because  our 
type  time  does  not  contain  values  corresponding  to  negative  numbers.  To  handle  this  problem,  we  transform 
any  equations  or  inequalities  involving  subtraction  of  time  values  so  that  they  involve  only  addition,  prior 
to  doing  PVS  proofs. 

Other  real-time  properties  of  a  timed  automaton  concern  the  relative  timing  of  events  during  an  admissible 
timed  execution.  Proofs  of  these  properties  often  involve  establishing  the  claim  that  if  the  automaton  is  in 
a  certain  state,  then  time  cannot  pass  beyond  a  certain  time  bound  unless  a  specified  event  occurs  prior  to 
the  bound.  As  indicated  above,  we  lack  a  specific  strategy  for  this  type  of  reasoning.  However,  we  do  have 
a  heuristic  that  often  works.  With  this  heuristic,  we  prove  by  induction  that  if  the  required  event  does  not 
occur  between  the  current  time  now(s)  and  the  time  bound,  then  some  component  of  the  state  involved  in 
the  precondition  for  time  passage  is  not  changed  by  subsequent  events,  and  that,  as  a  result,  the  precondition 
prevents  a  time  passage  event  from  crossing  the  bound.  It  is  likely  that  a  PVS  strategy  with  a  sufficient  set 
of  arguments  can  be  developed  to  set  up  a  proof  based  on  this  heuristic.  We  also  envision  an  interactive 
interface  that  guides  the  user  through  an  application  of  the  strategy  or  of  the  heuristic  directly. 

7  Related  Work 

An  effort  closely  related  to  ours  uses  the  Larch  Shared  Language  and  the  Larch  Prover  (LP)  to  prove  state 
invariants  and  simulations  for  real  time  systems  represented  as  timed  automata  [22].  In  this  approach,  proofs 
are  developed  in  LP  that  follow  hand  proofs,  but  proof  strategies  specialized  to  timed  automata  that  can 
support  a  close  correspondence  in  the  more  complex  induction  or  simulation  proofs  and  proofs  of  an  ad  hoc 
structure  are  not  included.  Whether  such  proof  strategies  can  be  developed  in  LP  to  the  same  extent  as  in 
PVS  is  an  open  question.  Other  efforts  have  used  PVS  in  proving  properties  of  real-time  systems  expressed  in 
different  formalisms.  For  example,  a  proof  assistant  that  encodes  the  Duration  Calculus  in  PVS  and  supports 
the  development  of  Duration  Calculus  specifications  and  proofs  of  real-time  properties  is  described  in  [34]. 
A  second  effort  whose  goal  is  to  make  formal  specification  and  theorem  proving  in  PVS  more  accessible  to 
hardware  design  practitioners  is  described  in  [35]. 
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8  Conclusions 


A  major  goal  of  our  research  is  to  make  the  use  of  an  automatic  theorem  prover  feasible  for  software 
developers.  Checking  properties  of  specifications  of  real-time  systems  with  a  mechanical  theorem  prover 
can  lead  to  the  early  discovery  of  inconsistencies  and  omissions  in  a  design.  We  envision  that  such  use 
of  automatic  provers  can  be  made  feasible  by  appropriate  automated  support.  Parts  of  this  support  may 
be  direct,  e.g.,  through  an  appropriate  interface  to  a  system  such  as  PVS  that  supports  specification  and 
automatic  theorem  proving.  Other  parts  of  it  may  be  indirect,  e.g.,  by  way  of  a  mechanism  for  arriving  at 
formal  specifications  that  are  understandable  to  both  the  developer  and  a  formal  methods  expert,  and  for 
creating  mechanically  checked  proofs  that  also  are  understandable  to  both. 

Our  early  results  are  encouraging.  For  real-time  systems  specified  in  the  timed  automata  model,  we  have 
developed  a  template  that  can  be  instantiated  in  a  straightforward  manner.  For  understandable  translations 
of  hand  proofs,  we  have  identified  PVS  proof  steps  that  correspond  to  natural  steps  in  hand  proofs.  We 
have  been  able  to  define  specialized  strategies  in  PVS  that  make  the  translation  of  hand  proofs  of  state 
invariants  into  recognizably  similar  PVS  proofs  straightforward  and  also  simple  enough  in  many  cases  that 
developers  themselves  could  create  them  through  an  appropriate  interface  to  PVS.  Such  an  interface  would 
perform  such  services  as  choosing  the  appropriate  instance  of  the  induction  strategy  or  the  invariant  lemma 
strategy  and  would  also  be  useful  to  the  formal  methods  expert  in  simplifying  the  proof  effort.  We  have 
defined ^additional  model-specific  strategies  that  can  be  useful  to  the  formal  methods  expert  in  translating 
more  complex  proofs  of  properties  of  designs  into  recognizable  PVS  equivalents. 

Although  PVS  strategies  such  as  GRIND  reduce  the  necessary  human  interaction  with  the  theorem  prover 
in  obtaining  a  proof,  the  reasoning  in  proofs  obtained  from  these  strategies  is  hard  to  follow.  In  contrast,  we 
have  found  that  human-understandable  PVS  proofs  can  be  derived  naturally  and  with  an  acceptable  level 
of  human  interaction  by  applying  a  set  of  domain-specific  strategies  in  the  course  of  following  a  hand  proof. 
Being  specialized,  these  strategies  result  in  proofs  with  a  significantly  shorter  execution  time  than  proofs 
based  on  GRIND.  There  is  also  an  advantage  in  undertaking  proofs  using  our  methods  and  strategies  when 
the  proof  does  not  succeed:  it  is  much  simpler  to  discover  the  reason  that  the  proof  does  not  succeed  when 
one  knows  exactly  the  corresponding  step  in  the  hand  proof. 

Similar  observations  apply  when  we  compare  our  methods  to  other  automata-based  formal  approaches 
to  reasoning  about  real-time  systems.  In  particular,  while  the  latter  can  be  used  to  prove  properties,  they 
provide  no  feedback  on  why  the  properties  are  true.  When  a  proof  fails,  a  tool  such  as  SMV  can  supply 
the  trace  of  a  counterexample.  While  this  information  is  helpful,  it  is  on  the  same  low  level  as  that  used  in 
software  debugging.  By  contrast,  the  information  provided  by  the  failure  of  a  mechanically  checked  hand 
proof  is  on  a  conceptual  level,  thus  providing  more  direct  information  on  where  one’s  assumptions  about 
a  particular  automaton  specification  are  incorrect.  Mechanically  checked  hand  proofs  have  an  additional 
advantage:  they  make  it  easier  to  predict  the  effects  of  changes  in  specifications  on  the  properties  of  the 
specified  automata.  In  addition,  when  these  changes  do  not  affect  the  validity  of  a  property,  checking  the 
property  can  often  be  done  by  modifying  the  former  proof  only  slightly,  or  not  at  all — as  opposed  to  rerunning 
a  time-consuming  algorithm  on  the  entire  specification. 

Our  use  of  PVS  as  a  basis  for  specification  and  proof  support  has  been  largely  successful.  Using  decision 
procedures  to  handle  the  obvious  low-level  reasoning  greatly  facilitates  the  creation  of  the  proofs.  Moreover, 
the  rich  specification  language  of  PVS  supports  both  parameterized  theories  and  higher-order  constructs 
that  allow  functions  and  predicates  to  be  used  as  record  components  and  theory  parameters.  As  a  result, 
once  one  has  identified  common  features  to  include  in  a  template,  expressing  the  template  in  PVS  is  largely 
straightforward  and  natural.  The  higher-order  logic  of  PVS  makes  it  possible  to  prove  useful,  reusable  high 
level  theorems  about  arbitrary  predicates  and  functions,  such  as  our  induction  principle. 

However,  the  current  version  of  PVS  does  not  always  satisfy  our  needs.  For  example,  it  imposes  some 
constraints  that  limit  the  directness  with  which  one  can  express  timed  automaton  specifications  and  trans¬ 
late  steps  from  hand  proofs.  At  least  one  case  has  arisen  where  it  would  be  helpful  to  have  parametric 
polymorphism  in  the  type  system,  as  is  the  case  in  HOL. 

The  limitation  on  specifications  is  visible  in  the  template  instantiation  of  the  timed  automaton  Trains ; 
the  status  component  of  a  state  of  Trains  is  represented  by  the  basic  component  of  the  state  of  the  PVS 
instantiation  trains,  rather  than  by  a  component  named  status.  An  auxiliary  function  definition  is  included 
in  the  PVS  version  to  permit  this  basic  component  to  be  referred  to  using  the  name  status .  The  natural 
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method  of  providing  a  template  for  the  type  state  with  slots  for  the  standard  parts  involving  time  and  timing 
is  to  define  type  state  as  a  record  type  with  standard  components.  In  addition  to  the  standard  components, 
the  state  of  any  particular  timed  automaton  may  have  an  arbitrary  number  of  specialized  state  components. 
Being  unable  to  define  a  parameterized  record  type  in  PVS  with  a  variable  number  of  components,  we  are 
constrained  to  use  a  single  slot,  to  which  we  give  the  standard  name  basic,  to  represent  these  additional 
specialized  components. 

In  translating  steps  from  hand  proofs  to  PVS,  there  are  cases  in  which  one  must  choose  the  appropriate 
version  of  a  PVS  strategy — say,  to  invoke  a  state  invariant  lemma — for  the  current  context.  While  this 
sometimes  might  be  done  using  a  single,  parameterized  strategy,  we  wish  to  relieve  the  user  of  providing 
(the  often  considerable  and  technical)  information  that  has  the  potential  to  be  supplied  automatically.  Both 
of  these  problems  could  be  eliminated  from  the  user’s  point  of  view  by  an  appropriate  interface  to  PVS. 
However,  there  are  other  limitations  of  PVS  as  it  stands  as  support  for  translating  hand  proofs  that  adding 
an  interface  cannot  eliminate,  such  as  the  need  to  refer  to  particular  assertion  numbers  when  applying  proof 
rules  (see  Section  5.2).  One  outcome  of  our  study  is  the  identification  of  a  number  of  features,  such  as 
the  ability  to  name  assertions  or  identify  them  by  contents,  that  would  remove  most  or  all  of  these  other 
limitations  if  added  to  PVS. 

An  example  difficulty  that  affects  both  specification  and  proof  is  the  problem  of  reasoning  about  extended 
non-negative  time.  In  both  mathematical  specification  and  hand  proof,  one  can  allow  a  larger  time  value  to 
be  subtracted  from  a  smaller  one  with  a  negative  number  as  the  result.  Because  we  have  had  to  define  type 
time  as  an  abstract  data  type  in  PVS,  time  values  cannot  easily  be  viewed  as  overlapping  real  number  values 
and  therefore  sharing  some  arithmetic.  In  fact,  the  result  of  subtracting  a  larger  time  value  from  a  smaller 
one  is  undefined.12  To  accomplish  specifications  and  proofs  equivalent  to  the  originals  in  [12],  we  have  had 
to  rephrase  any  equalities  involving  subtraction  as  equalities  involving  only  addition.  (See  the  definitions 
related  to  the  Utility  Property  in  Appendix  B.3.) 

The  lack  of  parametric  polymorphism  in  the  type  system  of  PVS  has  led  to  the  following  minor  frustration: 
in  timed  automata,  it  is  known  that  the  time  transition  action  changes  only  the  now  component  of  a  state. 
Thus,  other  state  components  are  equal  for  the  states  at  the  endpoints  of  a  time  transition  interval.  One 
cannot  state  a  general  lemma  to  this  effect  in  PVS  because  these  components  do  not  all  have  the  same 
type.  One  must  instead  prove  a  separate  invariance  lemma  for  each  individual  state  component.  With 
a  standardized  naming  structure  for  these  lemmas,  the  fact  that  they  are  separate  can  be  masked  on  the 
strategy  level  by  designing  the  strategy  to  invoke  the  appropriate  lemma  when  passed  the  name  of  a  state 
component  as  an  argument. 

9  TAME:  Recent  Developments 

Since  the  publication  of  [1],  our  system  for  supporting  the  methods  developed  in  this  study  was  given  the 
name  TAME  [2].  Further  developments  regarding  TAME  have  been  reported  in  [5],  [4],  and  [6].  TAME  has 
now  been  applied  with  some  success  to  multiple  examples  of  timed  and  non- timed  automata,  including  the 
boiler  controller  in  [21]  (see  [5,  3]),  a  vehicle  control  system  from  [36],  a  timed  version  of  Fischer’s  algorithm 
from  [23],  the  group  communication  service  in  [10,  9],  and  several  examples  of  SCR  specifications  (see  [6]). 13 

For  the  boiler  controller  and  vehicle  control  system,  TAME  was  extended  by  expanding  the  template 
conventions  to  cover  specifying  nondeterministic  transitions  using  Hilbert’s  “choice”  operator  e,  extending 
the  set  of  common  theories  to  include  a  theory  real_thy  containing  facts  about  real  numbers  helpful  in 
reasoning  about  real  arithmetic,  and  adding  a  new  strategy  to  the  standard  strategies  to  simplify  reasoning 
about  e.  A  slightly  modified  version  of  TAME’s  template  and  strategies  was  developed  for  reasoning  about 
SCR  specifications:  for  this  purpose,  it  has  proved  more  useful  to  represent  transitions  using  a  relation 
rather  than  a  function.  Although  TAME  was  developed  for  timed  automata,  it  can  also  be  used  without 
modification  for  non-timed  automata,  the  group  communication  service  being  an  example.  TAME  was  used 
in  a  somewhat  different  fashion  in  connection  with  this  example:  many  of  the  proofs  of  state  invariants  were 
undertaken  with  no  hand  proof  to  follow,  or  at  best  an  extremely  sketchy  hand  proof.  While  this  resulted  in 

12  We  could  have  simply  permitted  negative  time  values;  however,  doing  so  would  have  complicated  several  of  our  definitions, 
and,  therefore,  proofs  involving  reasoning  about  time.  For  example,  we  would  have  had  to  explicitly  state  that  the  value  of  now 
for  any  state  is  nonnegative. 

13 For  more  on  SCR  specifications,  see  [15,  17]. 
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Inv_6_3_A(s:  states):booI  =  (  FORALL  (r:  train):  status(r,s)  =  I  =>  gate_status(s)  =  fully_down  ); 

C 

(AUTO_INDUCT) 

(("  1 "  ;;Case  enterl(Itrainoflaction) 

(APPLY_SPECIFIC_PRECOND) 

(SUPPOSE  "gate_status(prestate)=fully_up  OR  gate„status(prestate)=going_up") 

(("1"  ;;Suppose  [gate_status(prestate)=fully_up  OR  gate_status(prestate)=going_up] 
(APPLYJN V_LEMM A  "6_  I "  "Itrainoflaction") 

(TRY_SIMP)> 

("2"  "Suppose  not  [gate_status(prestate)=fully„up  OR  gate_status(prestate)=going_up] 
(APPLY _INV_LEMMA  "6_2”  "Itrainoflaction") 

(APPLY_INV_LEMMA  "B_l_l") 

(TRY_SIMP)))) 

("2“  "Case  raise 

(APPLY„SPECIFIC_PRECOND) 

(INST  "specific-precondition”  "r_theorem") 

(APPLY_INV_LEMMA  "5_1JT  "r_theorem") 

(APPLY _INV_LEMMA  "5_1_3"  "r_theorem") 

(TRY_SIMP)) 

("3"  "Case  up 

(APPLY_SPECIFIC_PRECOND) 

(TRY.SIMP)))) _ 


Figure  12:  Updated  TAME  Proof  of  the  Safety  Property 

some  extra  backtracking  in  the  search  for  a  mechanical  proof,  many  of  the  proofs  of  simple  properties  were 
obtained  fairly  quickly.  Feedback  from  proofs  that  did  not  succeed  was  provided  to  the  authors  of  [10,  9],  and 
proved  helpful  in  suggesting  additional  state  invariants  needed  as  lemmas,  for  indicating  that  the  statements 
of  proposed  invariants  needed  revision,  of  for  suggesting  the  additional  guidance  needed  in  mechanizing  the 
proof.  For  one  complex  property  that  was  accompanied  by  a  detailed  hand  proof,  TAME  helped  to  reveal 
an  important  missing  case  not  covered  by  that  proof.  It  should  be  noted  that  many  extra  theories  for  the 
specialized  data  types  used  in  the  specification  of  the  group  communication  service,  and  corresponding  proof 
strategies  for  reasoning  about  these  types,  were  used  to  support  the  application  of  TAME  in  this  context.  In 
fact,  completing  the  checking  of  all  the  invariant  lemmas  in  [10,  9]  awaits  fuller  development  of  these  special 
data  type  theories.  Therefore,  while  TAME  has  proved  very  useful  for  this  application,  the  use  of  TAME  for 
this  and  similar  examples  entails  more  than  the  usual  overhead.  However,  this  overhead  and  more  would  be 
needed  in  any  ad  hoc  approach  to  mechanizing  proofs  of  properties  of  specifications  that  use  complex  data 
types. 

Based  on  a  preliminary  version  of  PVS  with  some  added  features — the  ability  to  generate  automatic  labels 
for  formulae  in  a  sequent,  the  ability  to  generate  automatic  comments  that  are  displayed  both  interactively 
and  in  saved  proofs,  the  ability  to  probe  into  the  content  of  formulae,  and  a  few  more  atomic  proof  steps — we 
have  solved  some  of  the  problems  noted  in  Sections  6.3  and  8.  In  particular,  comments  labeling  the  base  case 
and  induction  cases  of  a  state  invariant  induction  proof  are  now  generated  automatically,  as  are  comments 
showing  the  content  of  various  facts  applied  in  the  proof  such  as  preconditions,  previous  invariant  lemmas, 
or  suppositions.  Strategies  that  help  the  user  avoid  unnecessary  branching  in  mechanized  proofs  have  been 
or  are  being  developed.  Uniform  strategies  for  the  induction  step  and  the  application  of  invariant  lemmas 
now  exist,  and  with  the  added  PVS  features  plus  some  documentation  of  PVS  internals,  were  implemented 
internally  to  PVS,  without  an  external  interface.  This  work  is  discussed  in  [6].  As  an  example  of  how  TAME 
proofs  of  state  invariants  now  typically  appear  using  the  improved  TAME  strategies,  Figure  12  shows  the 
most  recent  version  of  the  PVS  proof  of  the  Safety  Property  in  Figure  11. 14  It  should  now  be  possible  to 
extend  TAME  with  the  strategies  proposed  in  Appendix  E  and  other  proof  steps  useful  in  ad  hoc  proofs. 

Future  plans  for  TAME  include  developing  user  interface  support  outside  of  PVS.  An  external  interface 
would  include  support  for  entering  the  application-specific  parts  of  specifications  into  the  TAME  template, 
and  support  for  automatic  translation  of  automata  specifications  in  other  specification  languages  into  TAME 

14For  clarity,  comments  generated  by  APPLY JSPECIFICLPRECOND  and  APPLY JNV-LEMMA  have  been  omitted. 


22 


form.  (There  is  a  preliminary  implementation  of  the  latter  for  SCR  specifications.)  The  interface  would  also 
handle  some  processing  of  a  specification  externally  to  PVS — for  example,  the  construction  of  application- 
specific  strategies  such  as  SYSTIMPLJSIMP.  In  addition,  we  expect  the  interface  to  provide  help  to  the 
user  in  the  form  of  simple  access  to  lemmas  from  all  relevant  theories  and  descriptions  of  existing  TAME 
strategies. 

So  far,  no  proof  support  has  been  developed  for  proofs  of  simulation  of  one  automaton  by  another. 
While  it  is  possible  to  provide  a  template  with  slots  for  two  automata  for  this  purpose,  accompanied  by 
appropriate  proof  strategies,  a  problem  arises  when  one  wishes  to  apply  a  lemma  previously  proved  for  one 
of  the  automata  in  the  course  of  a  proof:  this  automaton  has  been  specified  and  reasoned  about  in  a  separate 
theory.  When  theory  instantiations  become  available  in  PVS  as  planned  [32],  support  for  simulation  proofs 
is  feasible  in  a  form  we  desire. 
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A  Appendix.  The  Theory  atexecs:  Admissible  Timed  Executions 

Below  is  the  specification  of  the  (parameterized)  theory  atexecs  that  is  one  of  the  underlying  theories  of 
our  template  specification  for  timed  automata.  The  major  purpose  of  this  specification  is  the  definition 
of  the  type  atexecs.  This  definition,  which  closely  follows  the  description  of  admissible  timed  executions 
in  [12,  13],  represents  atexecs  as  a  complex  predicate  subtype  of  a  record  type  with  three  components: 
an  action  sequence,  a  trajectory  sequence,  and  a  time  sequence.  The  associated  predicate  restricts  these 
three-sequence  combinations  to  those  whose  first  trajectory  starts  with  a  start  state,  whose  trajectory  time 
bounds  connect  up,  whose  trajectory  end  points  are  connected  by  the  corresponding  actions,  and  whose  time 
sequence  satisfies  a  “greatest  lower  bound”  property  that  ensures  that  it  is  non-Zeno:  that  is,  as  the  index 
of  the  time  points  approaches  infinity,  so  does  the  indexed  time. 

The  definitions  after  that  of  atexecs  set  up  two  examples  of  lemmas  about  admissible  timed  executions, 
last-event  and  first-event,  that  eventually  will  be  used  to  support  useful  specialized  strategies.  For  example, 
the  strategies  using  these  lemmas  will  allow  one  in  a  single  PVS  step  to  follow  hand  proof  steps  of  the  form 
“let  7 r  be  the  last  (or  first)  event  before  (or  after)  state  s  that  has  property  F’. 

We  note  that,  as  with  the  template  definition  of  time  passage  events,  this  part  of  the  template  is  also 
more  restrictive  than  the  model  described  in  Section  2.2.  First,  we  enforce  the  condition  that  the  value 
of  now  in  any  admissible  timed  execution  must  approach  infinity  by  requiring  the  non-time-passage  events 
to  be  infinite  in  number  and  to  include  a  first  one  after  any  fixed  finite  time.  In  the  general  model,  an 
admissible  timed  execution  might  have  only  finitely  many  non-time-passage  events,  with  time  approaching 
infinity  through  successive  time-passage  events.  This  difference  is  not  really  significant,  since  one  can  always 
add  a  dummy  do-nothing  non-time-passage  action  at  infinitely  many  future  points  in  a  “finite”  admissible 
timed  execution.  The  second  difference  in  the  model  is  that  we  have  added  an  axiom  trajectory-unique  (see 
the  theory  opspec_atexecs_aux  in  Appendix  B.3)  whose  effect  is  to  ensure  that  there  are  no  repeating 
states  in  an  admissible  timed  execution.  A  later  state  that  repeats  an  earlier  state  could  result  only  from  a 
series  of  actions  occuring  in  zero  time;  otherwise,  the  later  state  would  have  a  different  time  component.  We 
do  not  believe  that  ignoring  executions  with  such  “loops”  is  inordinately  restrictive.  In  particular,  an  unsafe 
state  lasting  zero  time  should  be  unimportant,  and  properties  (such  as  the  utility  property  for  opspec) 
involving  time  intervals  should  be  unaffected  in  practice.  If  a  real  reason  to  permit  repeating  states  arises, 
we  could  add  the  concept  of  “state  occurrence”  on  which  to  base  some  of  our  reasoning. 


atexecs  [states,  actions:  TYPE, 
start:  [states  —  >  bool], 
now:  [states  — >  {r:real  |  r>=0}], 
step?:  [[states, actions, states]  ->  bool], 
nu:  [{r:real  |  r>0}  —  >  actions]]  :  THEORY 

BEGIN 

future:  TYPE  =  {r:real  |  r>=0}; 

k,m,nl,n2:  VAR  nat; 

z,tl,t2:  VAR  future; 

a:  VAR  actions; 

time-action? (a) :bool  =  (EXISTS  (t:future):  t  >  0  &  a  =  nu(t)); 

interval(tl,t2)(z):bool  =  (tl  <=  z  &  z  <=  t2); 

time-path:  TYPE  =  [#  ftime,length:future,  path: [(interval (ftime,ftime-l-length))— >states]  #]; 

ltime(w:time_path):future  =  ftime(w)  +  length(w); 

trajectory? (w:time_path):  bool  = 

(FORALL  (zl,z2:  (interval(ftime(w),ltime(w)))): 

zl<z2  =>  step?(path(w)(zl),nu(z2— zl),path(w)(z2))) 

&  (FORALL  (z:  (interval(ftime(w),ltime(w)))):  now(path(w)(z))  =  z); 

trajectory:  TYPE  =  (trajectory?); 
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fstate(w:trajectory):states  =  path(w)(ftime(w)); 
lstate(w:trajectory):states  =  path(w)(ltime(w)); 

time_seq:  TYPE  =  {t:[nat  ->  future]  |  t(0)=0  k  (FORALL  (nl,n2):  nl<=n2  =>  t(nl)<=t(n2))}; 
is_glb(z:future,t:time_seq,k:nat):bool  =  (t(k)  <=  z  k  (FORALL  (m):  m>k  — >  z  <  t(m))); 
has_glb(z:future,t:time_seq):bool  =  (EXISTS  (k):  is_glb(z,t,k)); 
pos_nat:  TYPE  =  {n:nat  |  n  >  0}; 

non_time_action:  TYPE  =  {a:actions  |  (NOT  (time -action?  (a)))}; 
action_seq:  TYPE  =  [pos_nat  —  >  non_time-action]; 

traj-seq:  TYPE  =  {w:[nat  — >  trajectory]  |  (FORALL  (k):  ltime(w(k))  =  ftime(w(k+l)))}; 

atexecs:  TYPE  =  {alpha  :  [#  pi:  action_seq,  w:  traj_seq,  t:  time-seq  #]  | 
start(fstate(w(alpha)  (0))) 

k  (FORALL  (k):  t(alpha)(k)=  ftime(w(alpha)(k))) 

k  (FORALL  (k):  step?(lstate(w(alpha)(k)),  pi(alpha)(k-fl),  fstate(w(alpha)(k+l)))) 
k  (FORALL  (z):  has_glb(z,t (alpha)))  }; 

%  The  definitions  and  lemmas  below  are  auxiliary  to  the  main  theory  atexecs.  They  serve  to 
%  illustrate  one  of  the  conveniences  of  a  theorem  proving  system  with  a  higher  order  logic:  one  can 
%  state  such  results  as  last-event  and  first-event  that  say  that  if  there  exists  an  event 
%  before  (after)  some  state  that  satisfies  some  property  Q,  then  there  is  a  last  (first)  such  event. 

in-trajectory  (w:  trajectory)  (s:states)  :bool  = 

(EXISTS  (t:future):  t  >=  ftime(w)  k  t  <=  ltime(w)  k  path(w)(t)  =  s); 

precedes(alpha:atexecs)(sl,s2:states):bool  = 

(now(sl)  <=  now(s2)) 

k  (EXISTS  (nl,n2):(in_trajectory(w(alpha)(n2))(s2)  k  in_trajectory(w(alpha)(n2))(s2) 
k  nl  <=  n2)); 

precedes_state(alpha:atexecs)(nl:posnat,s2:states):bool  = 

(t(alpha)(nl)  <=  now(s2)) 

k  (EXISTS  (n2):  (in_trajectory(w(alpha)(n2))(s2)  k  nl  <=  n2)); 

precedes-event(alpha:atexecs)(sl:states,n2:posnat):bool  = 

(now(sl)  <=  t(alpha)(n2)) 

k  (EXISTS  (nl):  (in_trajectory(w(alpha)(nl))(sl)  k  nl  <=  n2-l)); 

state_event_prop:  TYPE  =  [atexecs, states, posnat  —  >  bool]; 

Q:  state-event_prop; 

last-event:  LEMMA  (FORALL  (alpha:atexecs,  s:states,  P:state_event_prop): 

(LET  Q  —  (LAMBDA(alpha:atexecs,  s:states,  n:pos_nat): 

(precedes_state(alpha)(n,s)  k  P  (alpha, s,n))) 

IN  (FORALL  (n:posnat):  (Q(alpha,s,n)  — > 

(EXISTS  (m:  posnat):  m  >=  n  k  Q(alpha,s,m) 

k  (FORALL  (k:  posnat):  k  >~  m  k  Q(alpha,s,k)  =>  k  —  m)))))); 

first-event:  LEMMA  (FORALL  (alpha:  atexecs,  s:states,  P:state_e  vent  .prop): 

(LET  Q  =  (LAMBDA(alpha:atexecs,  s:states,  n:pos_nat): 

(precedes.event (alpha) (s,n)  k  P (alpha, s,n))) 

IN  (FORALL  (n:posnat):  (Q(alpha,s,n)  => 

(EXISTS  (m:  posnat):  m  <=  n  k  Q(alpha,s,m) 

k  (FORALL  (k:  posnat):  k  <=  m  k  Q(alpha,s,k)  — >  k  —  m)))))); 

END  atexecs 
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B  Appendix.  Specifying  the  GRC  Timed  Automata  Solution  in 
PVS 

The  specification  in  Figure  6  shows  how  the  definition  of  the  timed  automaton  Trains  from  [12,  13]  is 
represented  in  PVS.  Trains  is  a  component  of  each  of  the  timed  automata  used  in  deriving  a  solution  to  the 
Generalized  Railroad  Crossing  problem  in  [12,  13].  Figure  6  shows  only  the  declarations  needed  to  define 
the  automaton  Trains ;  the  full  theory  of  Trains  also  contains  lemmas  that  have  been  proved  about  the 
automaton. 

In  general,  when  using  the  template  shown  in  Figure  4,  it  has  proved  convenient  to  organize  the  full  theory 
of  a  timed  automaton  into  several  PVS  theories  that  group  definitions  and  lemmas  or  theorems  according  to 
their  significance,  and  to  import  these  separate  theories  either  directly  or  indirectly  into  a  trivial  top-level 
theory.  For  any  given  automaton  <  timed Mutomatonjname  >,  we  name  the  subsidiary  theories  according 
to  the  following  conventions: 

1.  <  timedMutomatonjname  >.decls  contains  the  definitions  required  to  instantiate  the  template; 

2.  <  timedMutomatonjname  >  .unique  .aux  contains  the  lemmas  that  document  the  fact  that  parame¬ 
terized  actions  with  distinct  arguments  are  distinct; 

3.  <  timedMutomatonjname  > .invariants  contains  the  state  invariant  definitions  and  corresponding  state 
invariant  lemmas  for  the  state  invariants  of  <  timedMutomatonjname  >; 

4.  <  timedMutomatonjname  >_atexecs_aux  contains  the  standard  definitions  and  “IMPORTING  atex- 
ecs”  declaration  to  define  the  admissible  timed  executions  of  <  timedMutomatonjname  >; 

5.  <  timedMutomatonjname  >_atexecs  contains  the  lemmas,  theorems,  and  any  supporting  definitions 
concerning  properties  of  the  admissible  timed  executions  of  <  timedMutomatonjname  >; 

6.  <  timedMutomatonjname  >jstrat_aux  contains  the  lemmas  needed  to  support  the  specialized  strate¬ 
gies  designed  for  use  in  the  ad  hoc  portions  of  proofs  of  properties  of  <  timedMutomatonjname  >; 

7.  <  timedMutomatonjname  >  is  the  trivial  top-level  theory  of  <  timedMutomatonjname  >  that  imports 
all  the  subsidiary  theories. 

The  subsidiary  theories  having  the  _aux  suffix  have  the  potential  of  being  generated  automatically  from 
the  information  in  the  <  timedMutomatonjname  >_decls  theory.  For  example, 

(A)  <  timedMutomatonjname  >  .unique _aux  can  be  generated  from  the  declaration  of  the  actions 
datatype; 

(B)  the  definitions  of  Now,  Nu ,  and  step?,  as  well  as  the  “IMPORTING  atexecs”  clause  in  the  theory 
axspec_atexecs_aux,  are  of  a  standard  form,  and  are  technically  part  of  (an  extended  form  of)  the 
template;  and 

(C)  the  lemmas  in  <  timedMutomatonjname  >_strat_aux  are  identical  in  form  for  all  applications. 

The  theory  <  timedMutomatonjname  >  .unique  .aux  in  (A)  contains  a  set  of  lemmas  about  the  unique¬ 
ness  of  actions  whose  content  is  not  part  of  the  knowledge  incorporated  in  existing  PVS  strategies,  but  which 
are  provable  in  PVS.15  In  fact,  the  proofs  of  these  lemmas  could  also  be  generated  automatically. 

The  syntactic  content  of  the  theories  in  (B)  and  (C)  is  fixed,  and  can  be  considered  an  extension  of  the 
template.  Note  that  the  lemmas  in  the  theory  <  timedMutomatonjname  >^strat_aux  need  to  be  proved 
at  some  point,  in  order  to  guarantee  the  soundness  of  proofs  obtained  using  strategies  that  depend  on  the 
lemmas.  These  lemmas  need  to  be  proved  in  an  environment  in  which  type  of  trans  is  known.  One  method 
for  providing  such  an  environment  is  to  import  a  theory  into  <  timedMutomatonjname  >_strat_aux, 

15The  information  that  they  contain  is  one  example  of  the  type  of  knowledge  that  is  “obvious”  to  a  human  but  not  to  PVS. 
Note  that  the  truth  of  this  information  depends  on  the  fact  that  there  are  no  equations  postulated  among  elements  of  the  data 
type  actions.  PVS  does  not  support  the  declaration  of  such  equations,  although  other  theorem  proving  systems,  including  LP, 
do  allow  them. 
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directly  or  indirectly,  in  which  trans  is  declared  (following  our  naming  conventions,  this  theory  should  be 
<  timed-automatoruname  >_decls).  This  is  the  method  used  in  the  specifications  in  this  Appendix.  Note 
that  it  requires  proving  the  lemmas  anew  for  each  timed  automaton.  Another  method  would  be  to  define 
the  lemmas  within  a  theory  to  which  trans  is  passed  in  as  a  parameter  of  known  type.  This  second  method 
is  used  in  our  second  template,  which  is  shown  in  Appendix  F.  Using  this  method,  the  lemmas  need  to  be 
proved  only  once,  at  the  top  level. 

The  connections  between  the  lemmas  in  the  theory  <  timed -automaton -name  >_strat_aux  and  our 
domain  specific  strategies  are  made  explicit  in  Appendix  C. 

Below,  we  present  four  full  PVS  theories  in  the  order  that  the  corresponding  timed  automata  are  defined 
in  [12,  13]:  trains,  the  theory  of  Trains ;  axspec,  the  theory  of  AxSpec ;  opspec,  the  theory  of  OpSpec ;  and 
systimpl,  the  theory  of  SystlmpL  Not  every  one  of  these  timed  automata  required  all  of  the  subtheories 
listed  above.  For  the  timed  automata  Trains  and  Systimpl,  we  have  only  needed  the  theories  described  in 
(1),  (2),  (3),  and  (7).  For  AxSpec ,  only  (1),  (2),  (4),  (5),  and  (7)  are  needed.  OpSpec  requires  all  seven 
subtheories. 

B.l  Appendix*  The  Full  Theory  of  Trains  in  PVS 

The  specification  in  Figure  6  shows  how  the  definition  of  the  timed  automaton  Trains  from  [12,  13]  is 
represented  in  PVS.  The  full  theory  trains  of  Trains  also  includes  one  invariant  lemma:  lemma_3_l.  In 
accordance  with  our  naming  conventions,  lemma-3_l  appears  in  the  subsidiary  theory  trains  invariants. 


trains.decls:  THEORY 
BEGIN 

IMPORTING  time_thy 

delta.t:  VAR  (fintime?) 
eps_l,  eps_2:  (fintime?) 

train:  TYPE 
r:  VAR  train 
actions  :  DATATYPE 
BEGIN 

nu(timeof: (fintime?)):  nu? 
enterR(Rtrainof:train):  enterR? 
enterI(Itrainof:train):  enterl? 
exit(Etrainof:train):  exit? 

END  actions 

a:  VAR  actions 

status:  TYPE  =  not_here,P,I 

MMTstates:  TYPE  =  [train  ->  status] 

IMPORTING  statesfactions, MMTstates, time, fintime?] 
status(r:train,  s:states):status  =  basic(s)(r) 

OKstate?(s:states):bool  =  true; 

enabled-general  (auctions,  s:states):bool  =  now(s)  >=  first(s)(a)  &  now(s)  <=  last(s)(a); 

enabled_specific  (aractions,  s:states):bool  — 

CASES  a  OF 

nu(delta-t):  (FORALL  r:  now(s)  +  delta_t  <=  last(s)(enterl(r))), 
enterR(r):  status(r,s)  =  not_here, 
enterl(r):  status(r,s)  =  P  &  first (s) (a)  <—  now(s), 
exit(r):  status(r,s)  =  I 
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ENDCASES 

trans  (a:actions,  s:states):states  = 

CASES  a  OF 

nu(delta_t):  s  WITH  [now  :=  now(s)  +  delta_t], 
enterR(r):  (#  basic  :=  basic(s)  WITH  [r  :=  P], 
now  :=  now(s), 

first  :=  first (s)  WITH  [(enterl(r))  :=  now(s)+eps_l], 
last  :=  last(s)  WITH  [(enterl(r))  :=  now(s)+eps_2]  #), 
enterl(r):  (#  basic  :=  basic(s)  WITH  [r  :=  I], 
now  :=  now(s), 

first  :=  first(s)  WITH  [(enterl(r))  :=  zero], 
last  :=  last(s)  WITH  [(enterl(r))  :=  infinity]  #), 
exit(r):  s  WITH  [basic  :=  basic(s)  WITH  [r  :=  not-here]] 

ENDCASES 

enabled  (a:actions,  s:states):bool  = 

enabled_general(a,s)  &  enabled_specific(a,s)  &  OKstate?(trans(a,s)); 

start  (s:states):bool  = 

s  =  (#  basic  :=  (LAMBDA  r:  not-here), 
now  :=  zero, 

first  :=  (LAMBDA  a:  zero), 
last  :=  (LAMBDA  a:  infinity)  #) 

IMPORTING  machine[states,  actions,  enabled,  trans,  start] 

END  trains  .decls 

trains_unique_aux:  THEORY 
BEGIN 

IMPORTING  trains_decls 

enterR_unique:  LEMMA  (FORALL  (rl,  r2:  train):  (enterR(rl)  =  enterR(r2)  =>  rl  =  r2)); 
enterl.unique:  LEMMA  (FORALL  (rl,  r2:  train):  (enterl(rl)  =  enterl(r2)  =>  rl  =  r2)); 
exit_unique:  LEMMA  (FORALL  (rl,  r2:  train):  (exit(rl)  =  exit(r2)  =>  rl  =  r2)); 
nu .unique:  LEMMA  (FORALL  (tl,  t2:  (fintime?)):  (nu(tl)  =  nu(t2)  =>  tl  =  t2)); 

END  trains -unique  _aux 

trainsJnvariants:  THEORY 
BEGIN 

IMPORTING  trains_unique_aux 

Inv.3_l(s:  states)  :bool  = 

(  FORALL  (r:  train):  (  status(r,s)  =  P  => 

first  (s)(enterl(r))  +  epS-2  -  eps.l  =  last(s)(enterl(r))  )  ); 

lemma-3-1:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv_3_l(s)  ); 

END  trainsJnvariants 

trains:  THEORY 
BEGIN 

IMPORTING  trainsJnvariants 
END  trains 
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B.2  Appendix.  Representing  the  Automaton  AxSpec  in  PVS 

Below,  we  present  the  theory  axspec,  which  is  the  translation  into  PVS  of  the  theory  of  the  automaton 
AxSpec  from  [12,  13]. 

The  automaton  AxSpec  includes  axiomatic  versions  of  the  Safety  and  Utility  Properties  as  part  of  its 
definition,  so  we  wish  to  include  these  in  the  full  corresponding  PVS  theory  axspec.  Since  the  Safety  and 
Utility  axioms  restrict  the  admissible  timed  executions  of  AxSpec ,  they  are  defined  in  the  subsidiary  theory 
axspec_at  execs. 

Note  that  the  use  of  subtraction  in  the  time  expressions  appearing  in  the  inequalities  involved  in  the 
definition  of  the  Utility  Property  axiom  has  been  avoided  by  following  the  convention  of  replacing  the 
inequalities  with  equivalent  ones  involving  only  addition.  Doing  this  results  in  reducing  the  number  and 
complexity  of  the  cases  to  be  considered  in  PVS  proofs  relying  on  these  inequalities.  It  also  ensures  that  the 
inequalities  have  the  same  semantics  as  if  they  permitted  negative  values  to  result  from  subtractions,  as  is 
typically  assumed  in  hand  proofs  involving  values  in  R -  U  {00} .  We  have  included  the  original  formulations 
of  the  definitions  for  comparison.  This  particular  convention  for  fitting  an  automaton  specification  to  our 
PVS  template  could  be  automated. 


axspec_decls:  THEORY 
BEGIN 

train:  TYPE; 
r,rl:  VAR  train; 

IMPORTING  time_thy 
t,  delta_t:  VAR  time; 

eps_l,  eps_2,  gamma_down,  gamma.up,  xLl,  xi_2,  delta:  (fintime?); 
actions  :  DATATYPE 
BEGIN 

nu(timeof:(fintime?)):  nu? 
enterR(Rtrainof:train):  enter R? 
enterI(Itrainof: train):  enterl? 
exit (Etrainof: train):  exit? 
lower:  lower? 
raise:  raise? 
up:  up? 
down:  down? 

END  actions; 

a:  VAR  actions; 

train_status:  TYPE  =  not_here,P,I; 

gate_status:  TYPE  —  fully aip,fully_down,going_up,going_down; 

MMTstates:  TYPE  =  [#  trains.part:  [train  ->  train_status],  gate.part:  gate_status  #]; 
IMPORTING  states[actions, MMTstates, time, fintime?] 
si:  VAR  states; 

status  (r:train,  s:states):train_status  =  trains_part(basic(s))(r); 
gate_status(s:states):gate„status  =  gate_part(basic(s)); 

OKstate?(s:states):bool  =  true; 

enabled_general  (auctions,  s:states):bool  =  now(s)  >=  first(s)(a)  &  now(s)  <—  last(s)(a); 

enabled-specific  (auctions,  s:states):bool  — 

CASES  a  OF 

nu(delta_t):  (delta.t  >  zero 

&  (FORALL  r:  now(s)  +  delta_t  <=  last(s)(enterl(r))) 
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&  now(s)  +  delta.t  <=  last(s)(up) 

&  now(s)  +  delta-t  <=  last(s)(down)), 
enterR(r):  status(r,s)  =  notJiere, 
enterl(r):  status(r,s)  =  P  &  first(s)(a)  <=  now(s), 
exit(r):  status(r,s)  =  I, 
lower:  true, 
raise:  true, 

up:  gate-status(s)  =  going.up, 
down:  gate_status(s)  =  going_down 
ENDCASES; 

trans  (auctions,  s:states):states  = 

CASES  a  OF 

nu(delta_t):  s  WITH  [now  :=  now(s)+delta.t], 
enterR(r):  s  WITH  [basic  :=  basic(s)  WITH 

[trains  .part  :=  trains.part(basic(s))  WITH  [r  :=  P]], 
first  :=  first(s)  WITH  [(enterl(r))  :=  now(s)+eps_l], 
last  :=  last(s)  WITH  [(enterl(r))  :=  now(s)+eps_2]], 
enterl(r):  s  WITH  [basic  :=  basic(s)  WITH 

[trains.part  :=  trains_part(basic(s))  WITH  [r  :=  I]], 
first  :=  first(s)  WITH  [(enterl(r))  :=  zero], 
last  :=  last(s)  WITH  [(enterl(r))  :=  infinity]], 
exit(r):  s  WITH  [basic  :=  basic (s)  WITH 

[trains-part  :=  trains_part(basic(s))  WITH  [r  :=  not  Jiere]]], 
lower:  IF  gate-status  (s)  =  fully.up  OR  gate-status  (s)  =  going.up 

THEN  s  WITH  [basic  :=  basic(s)  WITH  [gate.part  :=  going-down], 
last  :=  last(s)  WITH 

[down  :=  now(s)  4-  gamma-down,  up  :=  infinity]] 

ELSE  s  ENDIF, 

raise:  IF  gate_status(s)  =  fully.down  OR  gate-status (s)  =  going-down 

THEN  s  WITH  [basic  :=  basic(s)  WITH  [gate-part  :=  going_up], 
last  :=  last(s)  WITH 

[up  :=  now(s)  +  gamma.up,  down  :=  infinity]] 

ELSE  s  ENDIF, 

up:  s  WITH  [basic  :=  basic(s)  WITH  [gate.part  :=  fully.up], 
last  :=  last(s)  WITH  [up  :=  infinity]], 
down:  s  WITH  [basic  :=  basic(s)  WITH  [gate.part  :=  fully.down], 
last  :=  last(s)  WITH  [down  :=  infinity]] 

ENDCASES 

enabled  (auctions,  s:states):bool  =  enabled.general(a,s)  &  enabled_specific(a,s); 
start  (s:states):bool  = 

s  =  (#  basic  :=  (#  trains.part  :=  (LAMBDA  r:  notJiere),  gate.part  :=  fully.up  #), 
now  :=  zero, 

first  :=  (LAMBDA  a:  zero), 
last  :=  (LAMBDA  a:  infinity)  #); 

IMPORTING  machine[states,  actions,  enabled,  trans,  start] 

END  axspec.decls 
axspec  .unique _aux:  THEORY 

BEGIN 

IMPORTING  axspec.decls 

enterR.unique:  LEMMA  (FORALL  (rl,  r2:  train):  (enterR(rl)  =  enterR(r2)  =>  rl  =  r2)); 
enterl.unique:  LEMMA  (FORALL  (rl,  r2:  train):  (enterl(rl)  =  enterl(r2)  =>  rl  =  r2)); 
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exit-unique:  LEMMA  (FORALL  (rl,  r2:  train):  (exit(rl)  =  exit(r2)  =>  rl  =  r2)); 
nu.unique:  LEMMA  (FORALL  (tl,  t2:  (fintime?)):  (nu(tl)  =  nu(t2)  =>  tl  =  t2)); 

END  axspec -unique _aux 
axspec_at execs _aux:  THEORY 
BEGIN 

IMPORTING  axspec_unique_aux 

step?  (sl:states,  auctions,  s2:states):  bool  =  enabled(a,sl)  &  s2  =  trans(a,sl); 

Now  (s:  states):  {z:real  |  z>=0}  =  dur(now(s)); 

Nu  (z:  {z:real  |  z>0}):  actions  =  nu(fintime(z:  {z:real  |  z>=0})); 

IMPORTING  atexecs  [states,  actions,  start,  Now,  step?,  Nu] 

END  axspec_atexecs_aux 
axspec_atexecs:  THEORY 
BEGIN 

IMPORTING  axspec_atexecs_aux 

safety:  AXIOM  (FORALL  (alpha:  atexecs):  (FORALL  (s:  states): 

(in-atexec(alpha)(s)  =>  ((EXISTS  (r:train):  status(r,s)=I)  =>  gate-Status(s)=fully_down)))); 

%  utility_prop_a  (alpharatexecs,  s:states):  bool  — 

%  (EXISTS  (sl:states): 

%  (precedes(alpha)(sl,s)  &  (EXISTS  (r:train):  status(r,sl)  =  I)  &  now(sl)  >=  now(s)  -  xi_2)); 

utility_prop_a  (alpha:atexecs,  s:states):  bool  = 

(EXISTS  (sl:states): 

(precedes (alpha) (si, s)  &:  (EXISTS  (r:train):  status(r,sl)  =  I)  &  now(sl)  +  xi-2  >=  now(s))); 

utility-prop _b  (alpha:atexecs,  s:states):  bool  = 

(EXISTS  (sl:states): 

(precedes(alpha)(s,sl)  &  (EXISTS  (r:train):  status(r,sl)  =  I)  &  now(sl)  <=  now(s)  +  xi-1)); 

%  utility _prop_c  (alpha:at execs,  s:states):  bool  = 

%  (EXISTS  (sl,s2:states): 

%  precedes(alpha)(sl,s)  &  precedes  (alpha)  (s,s2) 

%  &  (EXISTS  (r:train):status(r,sl)— I)  &  (EXISTS  (r:train):status(r,s2)=I) 

%  &  now(s2)  —  now(sl)  <=  xi_l  -f  xi_2  +  delta); 

utility -prop  _c  (alpha:atexecs,  s:states):  bool  = 

(EXISTS  (sl,s2:states): 

precedes(alpha)(sl,s)  &  precedes  (alpha)  (s,s2) 

&  (EXISTS  (r:train):status(r,sl)=I)  &  (EXISTS  (r:train):status(r,s2)— I) 

&  now(s2)  <—  xi_l  +  xi_2  +  delta  -F  now(sl)); 

utility:  AXIOM  (FORALL  (alpha:  atexecs):  (FORALL  (s:  states): 

((in_atexec(alpha)(s)  &  NOT  (gate-status  (s)  —  fully  _up))  => 

(utility _prop_a(alpha,s)  OR  utility _prop_b (alpha, s)  OR  utility_prop_c(alpha,s))))); 

END  axspec .atexecs 
axspec  :  THEORY 
BEGIN 

IMPORTING  axspec_atexecs 
END  axspec 
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B.3  Appendix.  The  Timed  Automaton  OpSpec  in  PVS:  Version  1 

The  timed  automaton  OpSpec  defined  in  [12,  13]  is  the  composition  of  three  timed  automata:  Trains ,  Gate , 
and  CompSpec.  In  our  study,  we  have  first  composed  these  automata  by  hand  into  a  a  single  timed  automaton, 
which  we  then  defined  by  completing  our  template  specification. 

The  complete  theory  of  OpSpec  includes  several  state  invariant  lemmas  and  a  few  results  about  admissible 
timed  executions  of  OpSpec — most  notably,  two  major  theorems,  the  Safety  Property  and  the  Utility  Prop¬ 
erty  for  OpSpec ,  which  appear  in  the  theory  opspec_atexecs.  This  theory  also  contains  a  major  lemma 
{lemma-EA)  and  three  definitions  needed  to  state  and  prove  the  Utility  Property.  A  heavily  annotated 
version  of  the  PVS  proof  of  lemma^EJ  (which  corresponds  to  Lemma  E.l  in  [12])  appears  in  Appendix  E. 


opspec _decls:  THEORY 

BEGIN 

train:  TYPE 

r,rl:  VAR  train 

IMPORTING  time_thy 

beta.posreal:  {r:real  |  r  >  0}; 
delta_t:  VAR  (fintime?) 

eps.l,  eps_2,  gamma_down,  gamma-up,  xi_l,  xi_2,  delta:  (fintime?) 
beta: (fintime?)  —  fintime(beta_.posreal:{r:real  |  r  >=  0}); 

const-facts:  AXIOM 
(eps.l  <~  eps-2 
&  eps.l  >  gamma.down 

&  xi_l  >=  gamma-down  -f  beta  -I-  eps_2  —  eps.l 
&  xi-2  >=  gamma.up); 

actions  :  DATATYPE 

BEGIN 

nu(timeof: (fintime?)):  nu? 
enterR(Rtrainof:train):  enterR? 
enterI(Itrainof: train):  enterl? 
exit(Etrainof:train):  exit? 
lower:  lower? 
raise:  raise? 
up:  up? 
down:  down? 

END  actions; 

a:  VAR  actions; 

train_status:  TYPE  =  {not_here,P,I}; 

gate_status:  TYPE  =  {fully _up,fully_down,going_up, going-down}; 

MMTstates:  TYPE  =  [#  trains.part:  [train  —  >  train-status], 

gate_part:  gate_status, 

last-l.part,  last_2_up_part,  last_2J_part:  time  #]; 
IMPORTING  states[actions, MMTstates, time, fintime?] 
si:  VAR  states; 

status (r:train,  s:states):train_status  =  trains_part(basic(s))(r); 
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gate_status(s:states):gatej3tatus  =  gate-part  (basic(s)); 
last_l(s:states):time  —  last  _l_part  (basic  (s)); 
last_2_up(s:states):time  —  last_2_up_part(basic(s)); 
last_2_I(s:states):time  =  last_2  J_part  (basic  (s)); 

OKstate?  (srstates):  bool  = 

((EXISTS  (rrtrain):  status(r,s)  =  I)  — >  gate_status(s)  =  fully_down); 

OKstates:  TYPE  =  (OKstate?); 

enablecLgeneral  (auctions,  s:states):bool  — 

now(s)  >=  first(s)(a)  &  now(s)  <=  last(s)(a); 

enabled^specific  (aractions,  srstates)  :bool  = 

CASES  a  OF 

nu(delta.t):  (delta.t  >  zero 

&  (FORALL  r:  now(s)  +  delta.t  <=  last(s)(enterl(r))) 

&  now(s)  +  delta.t  <=  last (s)  (up) 

&  now(s)  +  delta.t  <=  last (s) (down) 

&  now(s)  +  delta_t  <=  last_l(s) 

&  now(s)  -1-  delta.t  <=  last_2J(s)), 
enterR(r):  status(r,s)  =  not-here, 
enterl(r):  status (r,s)  =  P  &  first (s) (a)  <=  now(s), 
exit(r):  status(r,s)  =  I, 
lower:  true, 
raise:  true, 

up:  gate_status(s)  =  going.up, 
down:  gate_status(s)  =  going_down 
ENDCASES; 

trans  (aractions,  srstates): states  = 

CASES  a  OF 

nu(delta_t):  s  WITH  [now  :=  now(s)+delta_t], 
enterR(r):  s  WITH  [basic  :=  basic(s)  WITH 

[trains_part  t  rains  .part  (basic  (s))  WITH  [r  :=  P]], 

first  :=  first(s)  WITH  [(enterl(r))  :=  now(s)-feps_l], 
last  :=  last(s)  WITH  [(enterl(r))  :—  now(s)+eps_2]], 
enterl(r):  s  WITH  [basic  :=  basic(s)  WITH 

[trains_part  :=  trains_part(basic(s))  WITH  [r  :=  I], 
las  t_l  .part  :=  infinity, 
last-2_up_part  :—  infinity, 
last_2JLpart  :=  infinity], 
first  :=  first(s)  WITH  [(enterl(r))  :=  zero], 
last  :=  last(s)  WITH  [(enterl(r))  :=  infinity]], 
exit(r):  LET  si  =  s  WITH  [basic  :=  basic(s)  WITH 

[trains_part  :=  trains_part(basic(s))  WITH 
[r  :=  not_here]]] 

IN  IF  (FORALL  (rl:  train):  (NOT  (rl  =  r))  =>  (NOT  status(rl,s)  -  I)) 
THEN  si  WITH  [basic  :=  basic(sl)  WITH 

[last_2_up_part  :=  now(s)  -f  xi_2, 
last_2 JLpart  :=  now(s)  +  xi_2  +  delta  +  xi_l]] 

ELSE  si  ENDIF, 

lower:  IF  gate_status  (s)  ~  fully _up  OR  gate_status(s)  =  going_up 
THEN  LET  si  =*  s  WITH 

[basic  :=  basic(s)  WITH  [gate_part  :—  going_down], 


last  :=  last(s)  WITH 

[down  :=  now(s)  *f  gamma_down,  up  :=  infinity]] 

IN  IF  last_l_part(basic(s))  =  infinity 
THEN  si  WITH 

[basic:=  basic(sl)  WITH  [last_l_part:=  now(s)+xi_l]] 
ELSE  si  ENDIF 
ELSE  s  ENDIF, 

raise:  IF  gate_status(s)  =  fully  .down  OR  gate_status(s)  =  going.down 

THEN  s  WITH  [basic  :=  basic(s)  WITH  [gate_part  :=  going-up], 
last  :=  last(s)  WITH 

[up  :=  now(s)  +  gamma-up,  down  :=  infinity]] 

ELSE  s  ENDIF, 

up:  LET  si  =  s  WITH  [basic  :=  basic(s)  WITH  [gate_part  :=  fully _up], 
last  :=  last(s)  WITH  [up  :=  infinity]] 

IN  IF  now(s)  <=  last_2_up_part(basic(s)) 

THEN  si  WITH  [basic  :=  basic(sl)  WITH 

[last_2_up_part:=  infinity,  last_2J_part:=  infinity]] 

ELSE  si  ENDIF, 

down:  s  WITH  [basic  :=  basic(s)  WITH  [gate_part  :=  fully-down], 
last  :=  last(s)  WITH  [down  :=  infinity]] 

ENDCASES 

enabled  (a:actions,  s:states):bool  = 

enabled_general(a,s)  &  enabled_specific(a,s)  &  OKstate?(trans(a,s)); 

start  (s:states):bool  = 

s  =  (#  basic  :=  (#  trains.part  :=  (LAMBDA  r:  not -here), 
gate.part  :=  fully _up, 
last_l_part  :=  infinity, 
last_2_up_part  :=  infinity, 
last_2JLpart  :=  infinity  #), 
now  :=  zero, 

first  :=  (LAMBDA  a:  zero), 
last  :=  (LAMBDA  a:  infinity)  #) 


rans,  start] 

END  opspec„decls 

opspec_unique_aux:  THEORY 
BEGIN 

IMPORTING  opspec_decls 

enter R.unique:  LEMMA  (FORALL  (rl,  r2:  train):  (enterR(rl)  =  enterR(r2)  =>  rl  =  r2)); 
enterLunique:  LEMMA  (FORALL  (rl,  r2:  train):  (enterl(rl)  —  enterl(r2)  =>  rl  =  r2)); 
exit-unique:  LEMMA  (FORALL  (rl,  r2:  train):  (exit(rl)  —  exit(r2)  =>  rl  =  r2)); 
nu.unique:  LEMMA  (FORALL  (tl,  t2:  (fintime?)):  (nu(tl)  =  nu(t2)  =>  tl  =  t2)); 

END  opspec_unique_aux 

opspecJnvariants:  THEORY 
BEGIN 

IMPORTING  opspec .unique _aux 
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Inv-4.1_l(s:  states):bool  = 

(  EXISTS  (r:  train):  (  statuses)  =  I  )  )  =>  gatej3tatus(s)  =  fully  .down; 
lemma_4_l_l:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv_4_l_l(s)  ); 

Inv_4_l_2(s:  states):bool  =  (  last_2_up(s)  4-  delta  +  xLl  =  last_2J(s)  ); 
lemma_4_l_2:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv_4_l_2(s)  ); 

Inv_4-2_l(s:  states):bool  =  (  now(s)  <=  last_l(s)  ); 

lemma_4_2_l:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv_4_2_l(s)  ); 

Inv_4_2_2(s:  states):bool  =  (  now(s)  <=  last_2_I(s)  ); 

lemma-4 _2_2:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv_4_2_2(s)  ); 

Inv_4_2_3(s:  states):bool  = 

(NOT  (last_l(s)  =  infinity))  =>  (  last_l(s)  <=  now(s)  4-  xi_l  ); 
lemma_4_2_3:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv_4_2_3(s)  ); 

Inv_4_2_4(s:  states) :bool  = 

(NOT  (last„2_I(s)  =  infinity))  =>  ( last_2J(s)  <=  now(s)  4*  xi_2  +  delta  4-  xi.l  ); 
lemma_4_2_4:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv-4-2_4(s)  ); 

Inv_4_2_5(s:  states) :bool  = 

(NOT  (last_2_up(s)  —  infinity))  =>  ( last_2iip(s)  <=  now(s)  4*  xi_2  ); 
lemma-4_2_5:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv-4_2_5(s)  ); 

END  opspec invariants 

opspec_atexecs_aux:  THEORY 
BEGIN 

IMPORTING  opspec invariants 

step?  (sl:states,  auctions,  s2:states):  bool  =  enabled(a,sl)  &  s2  =  trans(a,sl); 

Now  (s:  states):  {z:real  |  z>=0}  =  dur(now(s)); 

Nu  (z:  {z:real  |  z>0}):  actions  =  nu(fintime(z:  {z:real  |  z>— 0})); 

IMPORTING  atexecs  [states,  actions,  start,  Now,  step?,  Nu] 

A:  var  atexecs; 

reach_equiv:  LEMMA  (FORALL  (s:  states):  (FORALL  (n:  nat): 
steps_reach(n,  s)  —  >  reachable(s))); 

reach_equiv_2:  LEMMA  (FORALL  (s:  states):  (EXISTS  (n:  nat): 
steps  .reach  (n,  s))  — >  reachable(s)); 

reachability:  LEMMA  (FORALL  (alpha:  atexecs):  (FORALL  (s:  states): 

(in_atexec(alpha)(s)  =>  reachable(s)))); 

last _1  interval _0:  LEMMA  (FORALL  (alpha:  atexecs):  (FORALL  (j:  nat):  (FORALL  (s:  states) 
(in_trajectory(w (alpha) (j))(s)  =>  (last_l(s)  =  last_l(fst ate (w (alpha) (j) ))))))); 

last_linterval:  LEMMA  (FORALL  (alpha:  atexecs):  (FORALL  (j:  nat): 

(last-1  (lstate(w(alpha)  (j)) )  =  last  _l(fstate(w  (alpha)  (j )))))); 

gate_s  tat  us  interval-0:  LEMMA  (FORALL(alpha:atexecs):  (FORALL(j  mat) :  (FORALL  (s:states) : 
(in.trajectory (w(alpha) (j) ) (s)  =>  (gate_status(s)  =  gate_status(fstate(w(alpha)(j))) ))))); 
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gate_status  Jnterval:  LEMMA  (FOR ALL  (alpha:  atexecs):  (FORALL  (j:  nat): 

(gate_st  atus  (Is  t  ate  ( w  (alpha)  (j ) ) )  —  gate  jstatus  (fstate  (w  (alpha)  (j )))))) ; 

status JntervaLO:  LEMMA  (FORALL  (alpha:  atexecs):  (FORALL  (j:  nat):  (FORALL  (s:  states): 
(in-trajectory  (w(alpha)  (j) )  (s) 

— >  (FORALL  (r:  train):  (statuses)  =  status(r,fstate(w(alpha)(j))))))))); 

status  Jnterval:  LEMMA  (FORALL  (alpha:  atexecs):  (FORALL  (j:  nat):  (FORALL  (r:  train): 
(status(r,lstate(w(alpha)(j)))  =  status(r,fstate(w(alpha)(j))))))); 

last_2_upJnterval_0:  LEMMA  (FORALL  (alpha:atexecs):  (FORALL  (j:nat):  (FORALL  (s:states): 
(in_trajectory(w(alpha)(j))(s)  =>  (last_2-up(s)  =  last_2_up(fstate(w(alpha)(j)))))))); 

last_2_up Jnterval:  LEMMA  (FORALL  (alpha:  atexecs):  (FORALL  (j:  nat): 
(last_2_up(lstate(w(alpha)(j)))  =  last_2_up(fstate(w(alpha)(j)))))); 

last_2J JntervaLO:  LEMMA  (FORALL  (alpha:atexecs):  (FORALL  (j:nat):  FORALL  (s:states): 
(in_trajectory(w(alpha)(j))(s)  =>  (last-2J(s)  =  last_2_I(fstate(w(alpha)(j)))))))); 

last-2  J  Jnterval:  LEMMA  (FORALL  (alpha:  atexecs):  (FORALL  (j:  nat): 
(last_2J(lstate(w(alpha)(j)))  =  last_2J(fstate(w(alpha)(j)))))); 

trajectory-unique:  AXIOM  (FORALL(alpha:atexecs): (FORALL  (s:states): (FORALL  (nl,n2:nat): 
(in_trajectory(w (alpha) (nl)) (s)  k  in-trajectory(w(alpha)(n2))(s))  =>  nl  =  n2))); 

last_2 JJixed:  LEMMA  (FORALL  (alpha:  atexecs):  (FORALL  (j,k:  nat): 

(j<=k 

k  (FORALL  (m:  nat):  ( j  <  m  &  m  <=  k)  =>  (  not  (exit?  (pi  (alpha)  (m))) 

k  not(enterI?(pi(alpha)(m))) 
k  not(up?(pi(alpha)(m)))  ))  ) 

=>  last_2J(fstate(w(alpha)(k)))  =  last_2  J  (fstate  (w(alpha)(j))))); 
last_2_up_fixed:  LEMMA  (FORALL  (alpha:  atexecs):  (FORALL  (j,k:  nat): 

( j  <=  k 

k  (FORALL  (m:  nat):  ( j  <  m  &  m  <=  k)  =>  (  not(exit?(pi(alpha)(m))) 

&  not(enterI?(pi(alpha)(m))) 

&  not  (up?  (pi  (alpha)  (m)))  ))  ) 

=>  last_2_up(fstate(w(alpha)(k)))  =  last_2_up(fstate(w(alpha)(j ))))); 

END  opspec_at execs _aux 

opspec_strat_aux:  THEORY 
BEGIN 

IMPORTING  opspec-atexecs_aux 

event-times:  LEMMA  (FORALL  (alpha:atexecs,  n:nat): 
ftime(w (alpha)  (n))  =  t (alpha)  (n)  & 

Now  (path  (w(alpha)(n))(t  (alpha)  (n)))  =  t  (alpha)  (n)  & 
Now(path(w(alpha)(n))(ftime(w(alpha)(n))))  =  t(alpha)(n)  k 
dur(now(path(w(alpha)(n))(t(alpha)(n))))  =  t(alpha)(n)  & 
dur(now(path(w(alpha)(n))(ftime(w(alpha)(n)))))  =  t(alpha)(n)  k 
(n  >  0  =>  (ltime(w(alpha)(n  -  1))  =  t (alpha) (n)  k 

ftime(w(alpha)(n  -  1))  4-  length(w (alpha) (n-1))  =  t(alpha)(n)  k 
Now(path(w(alpha)(n  —  1)) (t (alpha) (n)))  =  t(alpha)(n)  k 
Now(path(w(alpha)(n  -  l))(ftime(w(alpha)(n))))  =  t(alpha)(n)  k 
dur(now(path(w(alpha)(n  —  l))(t (alpha) (n))))  =  t (alpha) (n)  k 
dur(now(path(w(alpha)(n  —  l))(ftime(w(alpha)(n)))))  =  t(alpha)(n)))); 
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same-states:  LEMMA  (FORALL  (alpha:atexecs,  n:nat): 
fstate(w(alpha)(n))  =  path(w(alpha)(n))(t(alpha)(n))  & 
lstate(w(alpha)(n))  =  path(w(alpha)(n))(t (alpha) (n  4-  1))  & 

(n  >  0  =>  lstate(w(alpha) (n— 1 ))  =  path(w(alpha)(n~l))(t (alpha) (n)))  & 

trans (pi (alpha) (n  4-  1),  lstate(w(alpha)(n)))  =  path (w (alpha) (n  4-  1) )(t (alpha) (n  -h  1))  & 

trans(pi(alpha)(n  4-  1),  path(w(alpha)(n))(t(alpha)(n  4-  1))) 

=  path (w (alpha) (n  -h  1)  )(t  (alpha)  (n  -h  1))  & 

LET  (dt:{z:real|z>=0})  =  t (alpha) (n  4-  1)  -  t (alpha) (n)  IN 

(dt  >=  0  &  (dt  >  0  =>  trans(nu(fintime(dt)),fstate(w(alpha)(n)))  —  lstate(w(alpha)(n))))) 

event-times_l:  LEMMA  (FORALL  (alpha: atexecs,  n:nat): 

ftime(w(alpha)(n))  —  t(alpha)(n)); 
event -times  _2:  LEMMA  (FORALL  (alpha:  atexecs,  n:nat): 

(t (alpha) (n-hl)  —  t (alpha) (n)  >=  0)  =  TRUE); 
event-times_3:  LEMMA  (FORALL  (alpha:at execs,  n:nat): 

(t  (alpha)  (n-hl)  >=  t(alpha)(n))  =  TRUE); 
event_times_4:  LEMMA  (FORALL  (alpha:atexecs,  n:nat): 

(t (alpha) (n)  <=  t (alpha) (n-hl))  =  TRUE); 
event _times„5:  LEMMA  (FORALL  (alpha:atexecs,  n:nat): 

Now(path(w(alpha)(n))(t(alpha)(n)))  =  t(alpha)(n)); 
event-times_6:  LEMMA  (FORALL  (alpha: atexecs,  n:nat): 

Now(path(w(alpha)(n))(ftime(w(alpha)(n))))  =  t(alpha)(n)); 
event_times-7:  LEMMA  (FORALL  (alpha: atexecs,  n:nat): 

dur(now(path(w(alpha)(n))(t(alpha)(n))))  =  t(alpha)(n)); 
event -times -8:  LEMMA  (FORALL  (alpha:atexecs,  n:nat): 

dur(now(path(w(alpha)(n))(ftime(w(alpha)(n)))))  =  t(alpha)(n)); 
event_times_9:  LEMMA  (FORALL  (alpha: atexecs,  n:nat): 

now(path(w(alpha)(n))(t(alpha)(n)))  =  fintime(t(alpha)(n))); 
event_times_10:  LEMMA  (FORALL  (alpha:atexecs,  n:nat): 

now  (path  (w  (alpha)  (n) )  (ft ime  (w  (alpha)  (n) ) ) )  =  fint ime  ( t  (alpha)  (n ) ) ) ; 
event_times-ll:  LEMMA  (FORALL  (alpha:  at  execs,  n:nat): 

ltime(w  (alpha)  (n))  =  t  (alpha)  (n4-l)); 
event _times_12:  LEMMA  (FORALL  (alpha:atexecs,  n:nat): 

ftime(w(alpha)(n))  4-  length (w (alpha) (n))  =  t(alpha)(n+l)); 
event_times-13:  LEMMA  (FORALL  (alpha: atexecs,  n:nat): 

length(w(alpha)(n))  4-  ftime(w  (alpha)  (n))  =  t  (alpha)  (n-hl)); 
event_times_14:  LEMMA  (FORALL  (alpha:atexecs,  n:nat): 

t(alpha)(n)  -h  length(w(alpha)(n))  =  t (alpha) (n-hl)); 
event  _times_15:  LEMMA  (FORALL  (alpha:atexecs,  n:nat): 

length(w(alpha)(n))  -h  t(alpha)(n)  =  t (alpha) (n-hl)); 
event_times_16:  LEMMA  (FORALL  (alpha:atexecs,  n:nat): 

Now(path(w(alpha)(n))(t(alpha)(n-hl)))  =  t  (alpha)  (n-hl)); 
event-times_17:  LEMMA  (FORALL  (alpha: atexecs,  nrnat): 

Now(path(w(alpha)(n))(ftime(w(alpha)(n4l))))  —  t  (alpha)  (n-hl)); 
event_times_18:  LEMMA  (FORALL  (alpha:atexecs,  n:nat): 

dur(now(path(w(alpha)(n))(t  (alpha)  (n4-l))))  =  t  (alpha)  (n-hl)); 
event_times_19:  LEMMA  (FORALL  (alpha:atexecs,  n:nat): 

dur(now(path(w(alpha)(n))(ftime(w(alpha)(n-hl)))))  =  t  (alpha)  (n-hl)); 
event_times_20:  LEMMA  (FORALL  (alpha:atexecs,  n:nat): 

now(path(w(alpha)(n))(t(alpha)(n+l)))  =  fintime(t(alpha)(n-hl))); 
event _times_21:  LEMMA  (FORALL  (alpha:atexecs,  n:nat): 

now(path(w(alpha)(n))(ftime(w(alpha)(n-hl))))  =  fintime(t(alpha)(n4l))); 
same-states _22:  LEMMA  (FORALL  (alpha:atexecs,  n:posnat): 

(t(alpha)(n)  —  t(alpha)(n— 1)  >=  0)  =  TRUE); 
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event-times-23:  LEMMA  (FORALL  (alpha:atexecs,  nrposnat): 

(t(alpha)(n)  >=  t(alpha)(n— 1))  =  TRUE); 
event_times_24:  LEMMA  (FORALL  (alpharatexecs,  n:posnat): 

(t(alpha)(n-l)  <=  t(alpha)(n))  =  TRUE); 
event_times_25:  LEMMA  (FORALL  (alpharatexecs,  nrposnat): 

ltime(w(alpha)(n-l))  =  t(alpha)(n)); 
event_times_26:  LEMMA  (FORALL  (alpharatexecs,  nrposnat): 

ftime(w(alpha)(n— 1))  +  length(w(alpha)(n~-l))  =  t(alpha)(n)); 
event_times_27:  LEMMA  (FORALL  (alpharatexecs,  nrposnat): 

length(w(alpha)(n— 1))  +  ft  ime(w  (alpha)  (n— 1))  =  t(alpha)(n)); 
event_times_28r  LEMMA  (FORALL  (alpharatexecs,  nrposnat): 

t(alpha)(n— 1)  +  length(w(alpha)(n-l))  =  t(alpha)(n)); 
event_times_29r  LEMMA  (FORALL  (alpharatexecs,  nrposnat): 

length(w(alpha)(n— 1))  +  t(alpha)(n— 1)  =  t(alpha)(n)); 
event_times_30:  LEMMA  (FORALL  (alpharatexecs,  nrposnat): 

Now(path(w(alpha)(n-l))(t(alpha)(n)))  =  t(alpha)(n)); 
event>times-31:  LEMMA  (FORALL  (alpharatexecs,  nrposnat): 

Now(path(w(alpha)(n-l))(ftime(w(alpha)(n))))  =  t(alpha)(n)); 
event _times_32r  LEMMA  (FORALL  (alpharatexecs,  nrposnat): 

dur(now(path(w(alpha)(n— l))(t(alpha)(n))))  =  t(alpha)(n)); 
event_times«33r  LEMMA  (FORALL  (alpharatexecs,  nrposnat): 

dur(now(path(w(alpha)(n-l))(ftime(w(alpha)(n)))))  =  t(alpha)(n)); 
event_times_34r  LEMMA  (FORALL  (alpharatexecs,  nrposnat): 

now(path(w(alpha)(n— 1))  (t  (alpha)  (n)))  =  fintime(t(alpha)(n))); 
event_times_35:  LEMMA  (FORALL  (alpharatexecs,  nrposnat): 

now(path(w(alpha)(n— l))(ftime(w(alpha)(n))))  —  fintime(t  (alpha)  (n))); 

trans-facts:  LEMMA  (FORALL  (alpharatexecs,  nrnat): 

trans(pi(alpha)(n+l),  lstate(w(alpha)(n)))  =  path(w  (alpha)  (n+l))(t  (alpha)  (n+l))  & 
trans(pi(alpha)(n+l),  path(w(alpha)(n))(t(alpha)(n+l))) 

=  path(w(alpha)(n+l))(t(alpha)(n-|-l))  & 

( (t  (alpha)  (n+1)  —  t  (alpha)  (n)  >  0)  => 

trans(nu(fintime((t(alpha)(n+l)  —  t(alpha)(n)):{r:real|r>=0})),  fstate(w(alpha)(n))) 

=  lstate(w(alpha)(n)))  & 

(n  >  0  => 

trans(pi(alpha)(n),  lstate(w(alpha)(n— 1)))  =  path(w(alpha)(n))(t(alpha)(n))  & 
trans(pi(alpha)(n),  path (w (alpha) (n— l))(t(alpha)(n)))  =  path(w(alpha)(n))(t (alpha) (n))  & 
((t (alpha) (n)  -  t(alpha)(n-l)  >  0)  => 

trans(nu(fintime((t (alpha) (n)  —  t(alpha)(n— l))r{r:real|r>=0})),  fstate(w(alpha)(n— 1))) 

=  lstate(w(alpha)(n— 1))))); 

samejstates.l:  LEMMA  (FORALL  (alpharatexecs,  nrnat): 

fstate(w(alpha)(n))  =  path(w(alpha)(n))(t(alpha)(n))); 
same_states_2r  LEMMA  (FORALL  (alpharatexecs,  nrnat): 

lstate(w(alpha)(n))  —  path(w(alpha)(n))(t(alpha)(n+l))); 
same_states_3:  LEMMA  (FORALL  (alpharatexecs,  nrposnat): 
lstate(w(alpha)(n— 1))  =  path(w(alpha)(n— 1))  (t  (alpha)  (n))); 

reachable_states:  LEMMA  (FORALL  (alpharatexecs,  nrnat): 
reachable(fstate(w(alpha)(n)))  & 
reachable(lstate(w(alpha)(n)))  & 
reachable(path(w(alpha)(n))(ftime(w(alpha)(n))))  & 
reachable(path(w(alpha)(n))(ltime(w(alpha)(n))))  & 
reachable(path(w(alpha)(n))(t(alpha)(n)))  & 
reachable(path(w(alpha)(n))(t(alpha)(n+l)))); 
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glbiact:  LEMMA  (FORALL  (alphaiatexecs,  Bifuture): 

(EXISTS  (k:nat):  t(alpha)(k)  <=  B  &  B  <  t(alpha)(k+l))); 

time_relation:  LEMMA  (FORALL  (alphaiatexecs,  tl,t2:nat): 

(tl  <=  t2  — >  t(alpha)(tl)  <=  t(alpha)(t2))  &  (t2  <=  tl  =>  t(alpha)(t2)  <—  t(alpha)(tl))); 

END  opspec_strats_aux 

opspec_atexecs:  THEORY 
BEGIN 

IMPORTING  opspecjstrat_aux 

lemma  JEJL:  LEMMA  (FORALL  (alpha:  atexecs):  (FORALL  (n:  pos_nat): 
pi(alpha)(n)  =  lower 

&  (gate_status(lstate(w(alpha)(n—  1)))  =  going-up  OR 
gate_status(lstate(w(alpha)(n-l)))  =  fully  _up)) 

=>  (EXISTS  (m:  pos_nat): 

(m  >  n  &  (EXISTS  (r:  train):  pi(alpha)(m)  =  enterl(r)) 

&  fintime(t (alpha)  (m))  <=  fintime(t (alpha)  (n))  4-  xi_l)))); 

safety:  THEOREM  (FORALL  (alpha:  atexecs):  (FORALL  (s:  states): 

(in_atexec(alpha)(s)  =>  ((EXISTS  (ritrain):  status (r,s)=I)  =>  gate_status(s)=fully_down)))); 

%  utility.prop^a  (alphaiatexecs,  sistates):  bool  — 

%  (EXISTS  (slistates): 

%  (precedes(alpha)(sl,s)  &  (EXISTS  (ritrain):  status(r,sl)  =  I)  &  now(sl)  >=  now(s)  —  xi_2)); 

utility_prop_a  (alphaiatexecs,  sistates):  bool  = 

(EXISTS  (slistates): 

(precedes(alpha)(sl,s)  &  (EXISTS  (ritrain):  status(r,sl)  =  I)  &  now(sl)  +  xi_2  >=  now(s))); 

utility _prop_b  (alphaiatexecs,  sistates):  bool  = 

(EXISTS  (slistates): 

(precedes(alpha)(s,sl)  &  (EXISTS  (ritrain):  status(r,sl)  =  I)  &  now(sl)  <~  now(s)  +  xi_l)); 

%  utility _prop_c  (alphaiatexecs,  sistates):  bool  = 

%  (EXISTS  (sl,s2:states): 

%  precedes(alpha)(sl,s)  k  precedes  (alpha)  (s,s2) 

%  k  (EXISTS  (r:train):status(r,sl)=I)  k  (EXISTS  (ritrain)  :status(r,s2)— I) 

%  k  now(s2)  —  now(sl)  <=  xi_l  -f  xi_2  +  delta); 

utility _prop_c  (alphaiatexecs,  sistates):  bool  = 

(EXISTS  (sl,s2:states): 

precedes  (alpha)  (si, s)  k  precedes(alpha)(s,s2) 
k  (EXISTS  (r:train):status(r,sl)=I)  k  (EXISTS  (ritrain) :status(r,s2)=I) 
k  now(s2)  <—  xi_l  +  xi_2  +  delta  +  now(sl)); 

utility:  THEOREM  (FORALL  (alpha:  atexecs):  (FORALL  (s:  states): 

((in_atexec(alpha)(s)  k  NOT  (gate-status  (s)  =  fully  _up))  — > 

(utility  _prop_a(alpha,s)  OR  utility _prop_b (alpha, s)  OR  utility^prop_c(alpha,s))))); 

END  opspec_atexecs 

opspec  :  THEORY 
BEGIN 

IMPORTING  opspec_atexecs 
END  opspec 
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B.4  Appendix.  The  Timed  Automaton  Systlmpl  in  PVS 

The  PVS  specification  of  the  full  theory  of  Systlmpl  is  structured  analogously  to  that  of  Trains. 


systimpl_decls:  THEORY 
BEGIN 
train:  TYPE 
r,rl:  VAR  train 
IMPORTING  time _thy 

beta.posreal:  {r:real  |  r  >  0}; 
delta.t:  VAR  (fintime?) 

eps.l,  eps-2,  gamma_down,  gamma„up,  xi_l,  xi_2,  delta:  (fintime?) 
beta: (fintime?)  =  fintime(beta_posreal:{r:real  |  r  >=  0}); 

const_facts:  AXIOM 
(  eps.l  <=  eps_2 
&;  eps-1  >  gamma-down 

&  xLl  -f  eps_l>=  gamma_down  +  beta  -f  eps.2 
&  xi_2  >=  gamma_up  ); 

actions  :  DATATYPE 
BEGIN 

nu(timeof: (fintime?)):  nu? 
enterR(Rtrainof: train):  enterR? 
enterI(Itrainof: train):  enterl? 
exit (Etrainof: train):  exit? 
lower:  lower? 
raise:  raise? 
up:  up? 
down:  down? 

END  actions; 

a:  VAR  actions; 

train_status:  TYPE  =  {notJiere,P,I}; 

gate-status:  TYPE  =  {fully-up,fully_down,going_up, going-down}; 
comp_train_status:  TYPE  =  {comp_not_here,R}; 
comp_gatejstatus:  TYPE  =  {comp_up,comp_down}; 

MMTstates:  TYPE  —  [#  trains  .part:  [train  —  >  train_status] , 

gate-part:  gate_status, 

comp-train_status_part:  [train  *~>  comp_train_status], 
comp_sched-time_part:  [train  — >  time], 
comp -gate  jstatus-part:  comp_gate_status  #]; 

IMPORTING  statesfactions, MMTstates, time, fintime?] 
si:  VAR  states; 

status(r:train,  s: states): train jstatus  =  trains_part(basic(s))(r); 
gatejstatus(s:states):gate_status  =  gate_part  (basic  (s)); 

comp_status(r:train,  s:states):comp_train-status  =  comp_train_status _part (basic (s))(r); 
sched_time(r: train,  s:states):time  =  comp_sched_time_part (basic (s))(r); 
comp_gatejstatus(s:states):comp_gate_status  =  comp_gate-Status_part  (basic  (s)); 
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OKstate?(s:states):bool  =  true; 

enabled-general  (auctions,  s:states):bool  =  now(s)  >=  first (s) (a)  &  now(s)  <=  last (s) (a); 

enabled_specific  (aractions,  s:states):bool  = 

CASES  a  OF 

nu(delta_t):  (delta.t  >  zero 

&  (FORALL  r:  now(s)  4-  delta.t  <=  last(s)(enterl(r))) 

&  now(s)  +  delta.t  <—  last(s)(up) 

&  now(s)  4-  delta_t  <—  last (s)  (down) 

&  (comp_gate_status(s)  =  comp_up  => 
enterR(r):  status(r,s)  =  notJiere, 
enterl(r):  status(r,s)  =  P  &;  first(s)(a)  <=  now(s), 
exit(r):  status (r,s)  —  I, 

(FORALL  r:  now(s)  4-  delta.t  4-  gamma.down  <  sched_time(r,s))) 

&  (comp_gate_status(s)  =  comp.down  => 

(EXISTS  r:  sched_time(r,s)  <= 

now(s)  4-  gamma_up  4-  delta  4-  gamma.down))), 
lower:  comp_gate_status(s)  =  comp.up 

&  (EXISTS  r:  sched-time(r,s)  <=  now(s)  4-  gamma.down  4-  beta), 
raise:  comp_gate_status(s)  =  comp.down 

&  (NOT  (EXISTS  r:  sched_time(r,s)  <=  now(s)4-gamma_up4~delta4~gamma_down)), 
up:  gate_status(s)  =  going.up, 
down:  gate_status(s)  =  going_down 
ENDCASES; 

trans  (auctions,  s:states):states  = 

CASES  a  OF 

nu(delta-t):  s  WITH  [now  :=  now(s)  4-  delta_t], 
enterR(r):  s  WITH  [basic  :=  basic(s)  WITH 

[trains .part  :=  trains-part (basic (s))  WITH  [r  :=  P], 
comp.train-status-part  := 

comp_train_status_part (basic (s))  WITH  [r  :—  R], 
comp_sched_time.part  := 

comp_sched_time_part (basic(s) )  WITH 
[r  :=  now(s)4-eps_l]], 

first  :=  first(s)  WITH  [(enterl(r))  :=  now(s)4-eps-l], 
last  :=  last(s)  WITH  [(enterl(r))  :=  now(s)4-eps-2]], 
enterl(r):  s  WITH  [basic  :=  basic(s)  WITH 

[trains.part  :=  trains.part  (basic  (s))  WITH  [r  I]], 
first  :=  first(s)  WITH  [(enterl(r))  :=  zero], 
last  :=  last(s)  WITH  [(enterl(r))  :=  infinity]], 
exit(r):  s  WITH  [basic  :=  basic(s)  WITH 

[trains-part  :=  trains.part (basic(s))  WITH  [r  :=  notJiere], 
comp.tr  ain_status.part  := 

comp_train_status_part(basic(s))  WITH  [r  :=  comp  mot -here], 
comp_sched.time.part  := 

comp_sched_time_part(basic(s))  WITH  [r  :=  infinity]]], 
lower:  IF  gate_status  (s)  =  fully  .up  OR  gate_status(s)  =  going.up 
THEN  s  WITH  [basic  :=  basic(s)  WITH 

[gate.part  going.down, 
comp_gate_status_part  :=  comp.down], 
last  :=  last(s)  WITH 

[down  :=  now(s)  4-  gamma.down,  up  :=  infinity]] 

ELSE  s  ENDIF, 
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raise:  IF  gate_status(s)  =  fully_down  OR  gate_status(s)  =  going.down 
THEN  s  WITH  [basic  :=  basic(s)  WITH 

[gate.part  going_up, 
comp_gate_status_part  comp.up], 
last  :=  last(s)  WITH 

[up  :=  now(s)  +  gamma.up,  down  :=  infinity]] 

ELSE  s  ENDIF, 

up:  s  WITH  [basic  :=  basic(s)  WITH  [gate.part  :=  fully _up], 
last  :=  last(s)  WITH  [up  :=  infinity]], 
down:  s  WITH  [basic  :=  basic(s)  WITH  [gate.part  :=  fully  .down], 
last  :=  last(s)  WITH  [down  :=  infinity]] 

ENDCASES 

enabled  (a:actions,  s:states):bool  =  enabled_general(a,s)  &  enabled_specific(a,s); 
start  (s:states):bool  = 

s  =  (#  basic  :=  (#  trains.part  :=  (LAMBDA  r:  notJiere), 
gate_part  :=  fully  .up, 

comp_train_status_part  :=  (LAMBDA  r:  comp_not_here), 
comp_sched_time_part  :=  (LAMBDA  r:  infinity), 
comp_gate_status_part  :=  comp.up  #), 

now  :=  zero, 

first  :=  (LAMBDA  a:  zero), 
last  :=  (LAMBDA  a:  infinity)  #) 

IMPORTING  machine[states,  actions,  enabled,  trans,  start] 

END  systimpl_decls 

systimpl.unique.aux:  THEORY 
BEGIN 

IMPORTING  systimpl.decis 

enterR-unique:  LEMMA  (FORALL  (rl,  r2:  train):  (enterR(rl)  =  enterR(r2)  =>  rl  =  r2)); 
enterl.unique:  LEMMA  (FORALL  (rl,  r2:  train):  (enterl(rl)  =  enterl(r2)  =>  rl  =  r2)); 
exit.unique:  LEMMA  (FORALL  (rl,  r2:  train):  (exit(rl)  =  exit(r2)  =>  rl  =  r2)); 
nu.unique:  LEMMA  (FORALL  (tl,  t2:  (fintime?)):  (nu(tl)  =  nu(t2)  =>  tl  =  t2)); 

END  systimpl.unique_aux 

systimplJnvariants:  THEORY 
BEGIN 

IMPORTING  systimpLunique_aux 

Inv.5-l_l(s:  states) :bool  =  (  FORALL  (r:  train): 

(comp_status(r,s)  =  R)  IFF  (status(r,s)  “  P  OR  status(r,s)  =  I)  ); 

lemma.5.1.1:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv_5.1_l(s)  ); 

Inv_5_l^(s:  states):bool  =  (  FORALL  (r:  train): 

(status(r,s)  =  P)  =>  (sched_time(r,s)  =  first (s)(enterl(r)))  ); 

lemma.5.1^:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv_5_l_2(s)  ); 

Inv_5_l_3(s:  states):bool  =  (  FORALL  (r:  train): 

(comp_status(r,s)  =  R  &  sched_time(r,s)  >  now(s))  =>  (status(r,s)  =  P)  ); 

lemma.5.1.3:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv_5_l_3(s)  ); 
Inv_5_l_4(s:states):bool  =  (FORALL  (r:train):  (status(r,s)  =  I)  =>  (sched_time(r,s)  <=  now(s))); 


43 


lemma_5-l_4:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =  >  Inv_5_l_4(s)  ); 

Inv_5_l_5(s:  states):bool  =  (  FORALL  (r:  train): 

(NOT  (sched_time(r,s)  =  infinity))  =>  (status(r,s)=P  OR  status(r,s)=I)  ); 

lemma_5_l_5:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv_5_l_5(s)  ); 

Inv_5_2_l(s:  states) :bool  = 

(comp_gate_status(s)  =  comp_up 
IFF  (gate_status(s)  =  fully _up  OR  gate_status(s)  =  going.up)); 

lemma-5_2_l:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv_5_2_l(s)  ); 

Inv_5_2-2(s:  states) :bool  = 

(comp_gate_status(s)  =  comp_down 
IFF  (gatejstatus(s)  =  fully -down  OR  gatejstatus(s)  =  going_down)); 

lemma-5-2_2:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv_5_2_2(s)  ); 

Inv_B_l_l(s:  states):bool  =  (  gate_status(s)  =  going-down  =>  last(s)(down)  >=  now(s)  ); 
n.  lemma-B_l_l:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv_B_l_l(s)  ); 

InvJBJL-2(s:  states):bool  =  (  gatejstatus(s)  =  going_down 
=>  last(s)(down)  <=  now(s)  +  gamma-down  ); 

lemma_B_l-2:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  InvJ3-l-2(s)  ); 

Inv_6_l(s:  states) :bool  =  (  FORALL  (r:  train): 

(  (  status(r,s)  =  P  &  (gatejstatus(s)  =  fully-up  OR  gate_status(s)  =  going.up)  ) 

=>  first (s)(enterl(r))  >  now(s)  +  gamma_down  )  ); 

lemmaJLl:  LEMMA  (  FORALL  (s:  states):  reachable(s)  — >  Inv_6_l(s)  ); 

Inv_6_2(s:  states):bool  =  (  FORALL  (r:  train): 

(  (status(r,s)  =  P  &  gate_status(s)  =  going-down)  =>  first (s)(enterl(r))  >  last(s)(down)  )  ); 

lemma_6_2:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv_6_2(s)  ); 

Inv«6-3(s:  states):bool  =  (  (EXISTS  (r:  train):  status(r,s)  =  I)  =>  gate_status(s)  =  fully_down  ); 
lemma_6_3:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv_6_3(s)  ); 

Inv_6_3_A(s:  states):bool  =  (  FORALL  (r:  train):  status(r,s)  =  I  =>  gate_status(s)  =  fully.down  ); 
lemma_6_3_A:  LEMMA  (  FORALL  (s:  states):  reachable(s)  =>  Inv_6_3_A(s)  ); 

END  systimplJnvariants 

systimpl:  THEORY 
BEGIN 

IMPORTING  systimplJnvariants 
END  systimpl 
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C  Appendix.  PVS  Strategies  for  Timed  Automata 

Below  are  the  definitions  of  the  user-defined  strategies  that  we  have  used  in  our  proofs  of  properties  of  timed 
automata,  organized  by  category.  The  strategies  used  in  induction  proofs  have  been  rather  finely  tuned  for 
efficiency  on  our  example  proofs. 

Most  of  the  strategies  developed  for  ad  hoc  proofs  are  expected  to  form  parts  of  higher-level  strategies, 
once  enhancements  to  PVS  permits  these  strategies  to  be  defined.  Examples  of  their  current  and  possible 
future  use  can  be  found  in  Appendix  E,  where  we  present  an  annotated  ad  hoc  proof  that  relies  on  them. 
The  strategy  file  “pvs-strategies”  presented  below  is  divided  into  nine  segments: 


Segment  1: 
Segment  2: 
Segment  3: 
Segment  4: 
Segment  5: 
Segment  6: 
Segment  7: 
Segment  8: 
Segment  9: 


Major  support  strategies  used  in  all  induction  strategies. 
Specialized  strategies  for  the  timed  automaton  Trains. 
Specialized  strategies  for  the  timed  automaton  OpSpec. 
Specialized  strategies  for  the  timed  automaton  Systlmpl 
Specialized  simplification  strategies  for  timed  automata. 
Apply-lemma  strategies  for  timed  automata. 

General  strategies  useful  in  reasoning  about  atexecs. 

A  special  tcc  strategy. 

Strategies  for  the  timed„auto  template  version. 


That  many  strategies  rely  on  the  form  of  the  template  is  clear  when  one  compares  the  strategies  in 
Segment  9  to  their  counterparts  in  Segments  1,  3,  and  7.  As  can  be  seen  from  examination  of  the  strategies, 
both  templates  provide  standard  names  for  functions  to  be  expanded  as  parts  of  strategies.  The  templates 
also  guarantee  the  form  of  the  definitions  of  these  functions,  and  the  form  of  critical  lemmas  such  as  “ma- 
chineinduct”  (the  basis  of  the  induction  strategies).  Knowledge  of  these  forms  is  taken  advantage  of  in 
various  calls  to  SPLIT,  LIFT-IF,  FLATTEN,  PROP,  and  INST.  An  obvious  example  is  the  definition  of  the 
strategy  time_etc_simp,  where  explicit  knowledge  of  the  forms  of  the  definitions  in  time_thy  is  used:  every 
arithmetic  operator  or  predicate  is  defined  as  an  iLthemelse,  so,  since  these  operators  may  occur  embedded 
in  expressions,  expansion  of  each  is  followed  by  a  LIFT-IF.  A  less  obvious  example  is  the  prop.probe  strat¬ 
egy  in  Segment  1,  which  is  used  by  the  induction  strategies  at  the  point  where  the  invariant  assertion  in 
the  inductive  conclusion  is  instantiated  with  the  state  specified  in  some  case  of  the  case  statement  defining 
trans.  When,  as  is  often  the  case,  this  state  is  specified  using  an  iLthemelse  construct,  the  call  to  LIFT-IF 
transforms  the  instantiated  invariant  assertion  itself  into  an  iLthen.else  construct,  which  can  then  be  split 
by  PROP  into  cases  that  may  be  provable  by  ASSERT. 

The  strategies  presented  divide  into  three  categories:  those  specialized  for  proof  of  state  invariants  that 
are  independent  of  timed  executions,  those  designed  to  support  recurring  types  of  reasoning  in  ad  hoc  proofs 
about  timed  executions,  and  those  that  are  useful  in  either  context.  The  strategies  in  Segments  1  through  4 
(and  some  of  those  in  Segment  9)  are  in  the  first  category.  So  far,  the  only  strategies  known  to  be  in  the  last 
category  are  the  simplification  and  apply-lemma  strategies  in  Segments  5  and  6.  The  strategies  in  Segment  7 
(and  their  relatives  in  Segment  9)  are  in  the  second  category. 

The  strategies  from  Segment  7  generally  depend  on  lemmas  about  admissible  timed  executions. 
The  theory  containing  these  lemmas  is,  in  the  conventions  of  our  first  template,  the  theory 
<  timed-automaton-name  >_strat_aux.  Certain  generic  parts  of  this  theory  can  be  included  as  a  sub¬ 
theory  of  atexecs,  say,  in  a  theory  atexecs_strat_aux.  However,  other  parts  of  this  theory  involve  generic 
function  names  from  parts  of  the  template  other  than  atexecs,  and  so  must  be  included  in  a  theory  in 
which  these  function  names  are  known.  Using  our  first  template,  we  are  constrained  to  use  some  sub-theory 
of  <  timed-automaton-name  >  for  this  purpose;  using  our  second  template,  we  can  use  the  generic  the¬ 
ory  timed^auto_thy.  So  far,  we  have  only  used  these  strategy  support  lemmas  to  reason  about  opspec; 
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hence,  to  simplify  matters  in  using  our  first  template,  we  have  grouped  all  of  the  strategy  support  lemmas 
in  opspec_strat_aux  (see  Appendix  B.3). 

The  Segment  7  strategies  provide  automated  support  for  handling  several  of  the  repeating  patterns  in 
proofs  about  admissible  timed  executions  that  were  mentioned  in  Section  6.  The  strategy  normalize_atexecs 
causes  alternative  representations  of  time  and  state  values  to  be  rewritten  into  a  standard  form,  simplifying 
many  proofs  that  two  expressions  represent  the  same  value.  Strategies  using  lemmas  containing  standard  facts 
about  reachability  and  states  related  by  trans  can  currently  be  used  to  retrieve  the  information  relevant  to  a 
certain  state  or  pair  of  states  given  the  name  of  the  relevant  atexecs  value  alpha  and  the  index  of  a  trajectory 
in  alpha  near  the  state  or  states  in  question.  These  strategies  already  help  simplify  the  proof  process.  For 
example,  in  combination  with  normalize_atexecs,  the  reachability  strategy  allows  one  to  simplify  the  process 
of  confirming  a  particular  state  is  reachable  as  a  prerequisite  to  applying  a  state  invariant  lemma  to  the 
state.  Provided  sufficient  tracking  and  recognition-by-content  of  assertions  is  added  to  PVS,  these  strategies 
could  be  refined  to  produce  exactly  the  required  information,  with  minimal  user  input  and  no  extra  clutter 
added  to  a  sequent.  In  fact,  it  should  be  possible  to  use  the  reachability  strategy  invisibly  to  the  user  as 
part  of  an  invariant-lemma  strategy. 

A  final  note  on  our  strategies:  many  of  them  were  developed  to  illustrate  feasibility,  and  require  further 
polishing.  E.g.,  the  use  of  standard  names  for  skolem  constants  is  a  danger,  since  one  must  assure  non¬ 
duplication  of  names  associated  with  a  given  type.  One  advantage  of  standard  names  is  that  their  significance 
is  also  standard.  Ideally,  automatic  generation  of  these  skolem  constants  will  be  accompanied  by  some 
method  of  tracking  their  significance.  This  might  be  done  through  an  interface  to  PVS.  There  is  another 
naming  problem  as  well.  When  two  or  more  automaton  theories  are  being  reasoned  about  simultaneously, 
the  standard  names  of  template  operators  will  have  more  than  one  instantiation.  For  the  strategies  to  work 
in  such  a  situation,  they  will  have  to  use  the  correct  instantiations  of  these  operators  when  they  are  invoked. 
The  best  way  to  obtain  the  information  needed  to  determine  these  instantiations  needs  to  be  determined. 


Section  1 

Major  support  strategies  used  in  all  induction  strategies. 

(defstep  auto_cases  (inv) 

(then*  (lemma  “machine induct” ) 

(expand  “inductthm”) 

(inst  -1  inv) 

(split)) 

“Splitting  into  machine  base  and  induction  cases”) 

(defstep  base-case  (inv) 

(then*  (delete  2) 

(expand  “base”) 

(skolem  1  “s_l”) 

(flatten) 

(expand  “start” ) 

(expand  inv)) 

“”  “Simplifying  the  machine  base  case” ) 

(defstep  induct  .cases  (inv) 

(let  ((x  (format  nil  “  ~a  ~a  ~a  ~a  ~a” 

“(LAMBDA  (a:  actions):  (FORALL  (s:  states):  reachable(s)  &  ” 
inv 

“(s)  &  enabled(a,s)  =>  ” 
inv 

“(trans(a,s) )))”))  ) 

(then*  (delete  2) 

(expand  “inductstep” ) 

(lemma  “actionsinduction”) 

(inst  —lx) 
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(beta) 

(branch  (split) 

((then*  (skolem  1  (“sJ”  “a_l”))(inst  -1  “a_l”)(inst  -1  “s_l”)) 

(skip))))) 

“Splitting  the  induction  case  on  action  class”) 

(defstep  reduce.case_one.var_exp  (inv  varl) 

(then*  (delete  2) 

(skolem  1  (varl)) 

(skolem  1  (“s_l”)) 

(flatten) 

(expand  “enabled”) 

(expand  “trans”) 

(expand  inv)) 

“”  “Applying  the  standard  simplification”) 

(defstep  reduce_case_no_var_exp  (inv) 

(then*  (delete  2) 

(skolem  1  (“s_l”)) 

(flatten) 

(expand  “enabled”) 

(expand  “trans”) 

(expand  inv)) 

“”  “Applying  the  standard  simplification”) 

;  The  strategy  reduce_case_no_var_rew  is  just  like  reduce_case_no_var_exp  except  that  it  calls  rewrite 
;  instead  of  expand  on  trans  in  order  to  avoid  doing  the  lift-if  included  in  an  expand  that  spoils  the  matching 
;  of  universally  quantified  formulae  in  inductive  hypothesis  and  conclusion.  The  choice  of  strategy  is  made 
;  according  to  whether  there  is  an  IF-THEN-ELSE  at  the  top  level  of  the  definition  for  the  corresponding 
;  case  in  the  definition  of  trans.  The  use  of  rewrite  on  expand  as  well  is  the  result  of  experiment  showing 
;  it  to  be  more  efficient  in  this  case. 

(defstep  reduce_case_no_var jrew  (inv) 

(then*  (delete  2) 

(skolem  1  (“s_l”)) 

(flatten) 

(rewrite  “enabled”) 

(rewrite  “trans”) 

(expand  inv)) 

“”  “Applying  the  standard  simplification”) 

;  The  strategy  prop  .probe  is  used  to  test  whether  the  remainder  of  a  proof  is  “trivial” .  It  is  part  of 
;  several  other  “_probe”  strategies. 

(defstep  prop.probe  () 

(then*  (lift-if) 

(prop) 

(assert) 

(fail)) 

;  ***  Section  2  *** 

;  ***  Specialized  strategies  for  the  timed  automaton  trains.  *** 

(defstep  auto_proof_trains  (inv) 

(then  (branch  (auto.cases  inv) 

((then  (base_case  inv) (trains jsimp.probe) (postpone)) 

(branch  (induct.cases  inv) 
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((then  (reduce.case.one.var.exp  inv  “t.l”) 
(trains  jsimp_probe)  (postpone) ) 
(then  (reduce_case_one_var_exp  inv  “r.l”) 
(trains_simp  -probe)  (postpone) ) 
(then  (reduce_case_one_var_exp  inv  “r.l”) 
(trains-simp.probe)  (postpone) ) 
(then  (reduce.case.one.var.exp  inv  “r.l”) 
(trains_simp_probe)  (postpone)) ) ) ) ) ) 

“Taking  care  of  the  standard  steps  in  the  proof’) 

(defstep  auto_proof_univ_trains  (inv) 

(then  (branch  (auto.cases  inv) 

(then  (base.case  inv)  (trains_simp_probe)  (postpone)) 
(branch  (induct .cases  inv) 

((then  (reduce.case_one.var .exp  inv  “t.l”) 
(match_univ_and_trains_simp_probe) 
(postpone)) 

(then  (reduce_case_one_var_exp  inv  “r.l”) 
(match_umv_and_trains_simp.probe) 
(postpone)) 

(then  (reduce_case_one.var.exp  inv  “r.l”) 
(match_univ_and_trains-simp_probe) 
(postpone)) 

(then  (reduce.case_one_var.exp  inv  “r.l”) 
(match_univ_and_trains_simp_probe) 
(postpone))))))) 

“Taking  care  of  the  standard  steps  in  the  proof’ ) 

(defstep  trains_simp  () 

(then*  (expand  “OKstate?”) 

(expand  “status”) 

(flatten)) 

“”  “Expanding  some  trains  definitions”) 

(defstep  trains_simp_probe  () 

(then  (trains-simp)  (prop.probe)) 

UJJ  ^ 

(defstep  mat ch_univ_and_trains_simp .probe  () 

(then  (skolem  1  “r_2”)  (inst  -2  “r_2”)  (trains_simp_probe)) 


;  ***  Section  3 

;  ***  Specialized  strategies  for  the  timed  automaton  opspec. 

;  The  auto.proof  strategies  are  the  induction  strategies. 

(defstep  auto.proof.opspec  (inv) 

(then  (branch  (auto.cases  inv) 

(then  (base.case  inv) (opspec_simp .probe) (postpone)) 
(branch  (induct.cases  inv) 

((then  (reduce.case_one_var.exp  inv  “t.l”) 
(opspec-simp.probe)  (postpone)) 
(then  (reduce_case.one.var.exp  inv  “r.l”) 
(opspec_simp  .probe)  (postpone)) 
(then  (reduce _case_one.var.exp  inv  “r.l”) 
(opspec-simp.probe)  (postpone) ) 
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(then  (reduce.case_one_var.exp  inv  “r.l”) 
(opspec_simp_probe)  (postpone) ) 
(then  (reduce_case_no_var_exp  inv) 

(opspec_simp_probe)  (postpone)) 
(then  (reduce_case_no_var_exp  inv) 

(opspec_simp  .probe)  (postpone)) 
(then  (reduce_case_no_var_exp  inv) 

(opspec-simp.probe)  (postpone) ) 
(then  (reduce_case_no_var_exp  inv) 

(opspec_simp  .probe)  (postpone) )))))) 
“Taking  care  of  the  standard  steps  in  the  proof’ ) 

(defstep  opspec_simp  () 

(then*  (expand  “OKstate?”) 

(expand  “last.l”) 

(expand  “last_2_up”) 

(expand  “last_2J”) 

(expand  “status”) 

(expand  “gate_status”) 

(flatten)) 

“”  “Expanding  some  opspec  definitions” ) 


(defstep  opspec_simp_probe  () 

(then  (opspec_simp)  (prop .probe)) 

«?>  «5)  \ 


The  strategy  do.trans.opspec  expands  and  simplifies  a  state  of  opspec  that  is  represented  by  a  trans 
expression,  and  reasons  about  the  result.  Because  trans  is  usually  defined  by  a  case  expression,  it  is 
not  unusual  for  branching  to  occur.  It  is  typical  for  the  expected  number  of  branches  to  be  small  when 
do.trans.opspec  is  an  appropriate  proof  step. 

(defstep  do.trans.opspec  () 

(then  (expand  “trans”  )(opspec_simp)(lift-if) (assert) (assert)) 

«)3  ^ 

***  Section  4  *** 

***  Specialized  strategies  for  the  timed  automaton  systimpl.  *** 


The  auto_proof  strategies  are  the  induction  strategies. 

(defstep  auto.prooLsystimpl  (inv) 

(then  (branch  (auto.cases  inv) 

(then  (base.case  inv)  (systimpl_simp_probe)  (postpone)) 
(branch  (induct .cases  inv) 

((then  (reduce_case_one_var_exp  inv  “t.l”) 
(systimpLsimp.probe)  (postpone) ) 
(then  (reduce.case.one.var.exp  inv  “r_l”) 
(systimpl  .simp.probe)  (postpone) ) 
(then  (reduce_case_one_var_exp  inv  “r.l” ) 
(systimpLsimp.probe)  (postpone) ) 
(then  (reduce.case.one_var.exp  inv  “r_l”) 
(systimpl_simp_probe)  (postpone) ) 
(then  (reduce.case Jio.var.exp  inv) 

(systimpl_simp_probe)  (postpone) ) 
(then  (reduce_case_no_var_exp  inv) 

(systimpl_simp_probe)  (postpone) ) 
(then  (reduce_case_no_var_exp  inv) 
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(systimpLsimp.probe)  (postpone) ) 

(then  (reduce.case_no_var.exp  inv) 

(systimpl_simp_probe)  (postpone) )))))) 

“Taking  care  of  the  standard  steps  in  the  induction  proof 5 ) 

(defstep  auto_proof_univ_systimpl  (inv) 

(then  (branch  (auto.cases  inv) 

(then  (base.case  inv) (systimpl_simp_probe) (postpone)) 
(branch  (induct.cases  inv) 

((then  (reduce.case_one_var.exp  inv  “t_l”) 

(match_univ_and_systimpl_simp_probe) 

(postpone)) 

(then  (reduce_case_one.var.exp  inv  “r.l”) 

(match_univ.and_systimpl.simp  .probe) 
(postpone)) 

(then  (reduce.case_one_var_exp  inv  “r_l”) 

(match_univ_and_systimpl_simp_probe) 

(postpone)) 

(then  (reduce_case_one_var_exp  inv  “r.l”) 

(match_univ_and_systimpl_simp_probe) 

(postpone)) 

(then  (reduce.case _no_var  jew  inv) 

(match_univ_and_systimpl_simp_probe) 

(postpone)) 

(then  (reduce_case_no_var _rew  inv) 

(match_univ_and_systimpl_simp_probe) 

(postpone)) 

(then  (reduce.casejno.var.exp  inv) 

(match_univ_and_systimpl_simp_probe) 

(postpone)) 

(then  (reduce_case_no~var_exp  inv) 

(match_univ_and_systimpl_simp_probe) 

(postpone))))))) 

“Taking  care  of  the  standard  steps  in  the  induction  proof’ ) 

(defstep  systimpl_simp  () 

(then*  (expand  “OKstate?”) 

(expand  “beta”) 

(expand  “comp_status” ) 

(expand  “comp_gate_status” ) 

(expand  “sched.time” ) 

(expand  “status”) 

(expand  “gate_status” ) 

(flatten)) 

“”  “Expanding  some  systimpl  definitions” ) 

(defstep  systimpl_simp_probe  () 

(then  (systimpl_simp)  (prop .probe)) 

UV  ^ 

(defstep  match_univ.and-systimpl_simp_probe  () 

(then  (skolem  1  “r_2”)  (inst  -2  “r_2”)  (systimpl_simp_probe)) 

a»  ur>  ^ 

(defstep  direct-proof-univ_systimpl  (inv) 

(then*  (skolem  1  “s.l”) 
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(expand  inv) 

(flatten) 

(skolem  1  “r_l”) 

(systimpl_simp)) 

“”  “Doing  the  standard  steps  of  a  non-induction  proof’) 

;  ***  Section  5 

;  ***  Specialized  simplification  strategies  for  timed  automata. 

;  Simplification  strategies  that  handle  time  definitions  and  other  simple  types  of  reasoning  needed  for 
;  timed  automata. 

(defstep  time_etc_simp  () 

(then*  (lift-if) 

(prop) 

(assert) 

(expand  “<=”) 

(lift-if) 

(expand  “>=”) 

(lift-if) 

(expand  “<”) 

(lift-if) 

(expand  “>”) 

(lift-if) 

(expand  “4-”) 

(lift-if) 

(expand  “—”) 

(lift-if) 

(repeat*  (then*  (assert)  (prop)  (lift-if)))) 

“Doing  time-arithmetic”) 

;  The  strategy  time_etc_simp .probe  tries  time_etc_simp  and  backtracks  if  it  does  not  succeed. 

(defstep  time.etc_simp_probe  () 

(then*  (lift-if) 

(prop) 

(assert) 

(expand  “<=”) 

(lift-if) 

(expand  “>=”) 

(lift-if) 

(expand  “<”) 

(lift-if) 

(expand  “>”) 

(lift-if) 

(expand  “+”) 

(lift-if) 

(expand  “— ”) 

(lift-if) 

(repeat*  (then*  (assert)  (prop)  (lift-if))) 

(fail)) 

“Doing  time-arithmetic”) 

;  The  strategy  time_simp  focusses  time.etcjsimp  on  a  single  formula  in  a  sequent. 

(defstep  time_simp  (fnum) 

(then*  (lift-if  fnum) 
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(my .prop  fnum) 

(assert) 

(expand  “<— ”  fnum) 

(lift-if  fnum) 

(expand  “>=”  fnum) 

(lift-if  fnum) 

(expand  “<”  fnum) 

(lift-if  fnum) 

(expand  “>”  fnum) 

(lift-if  fnum) 

(expand  fnum) 

(lift-if  fnum) 

(expand  “— ”  fnum) 

(lift-if  fnum) 

(repeat*  (then*  (assert)  (my  .prop  fnum)  (lift-if  fnum)))) 
“Doing  time-arithmetic  on  a  particular  formula”) 


;  The  strategy  my  .prop  focusses  the  standard  strategy  prop  on  a  single  formula  in  a  sequent. 

(defstep  my  .prop  (fnum) 

(try  (flatten  fnum)  (my_prop  fnum)  (try  (split  fnum)  (my_prop  fnum) (skip))) 

;  The  following  shorter  version  of  time_etc_simp  was  provided  by  Shankar  at  SRI.  It  is  equivalent  in  power 
;  to  time_etc_simp,  but  testing  has  shown  that  while  it  is  sometimes  equally  fast,  it  is  sometimes  several 
;  seconds  slower. 

(defstep  time  _etc_simp  .shankar  () 

(then  (stop-rewrite) 

(auto-rewrite-theory  “time.thy” ) 

(repeat*  (then  (lift-if) (ground)))) 

“Doing  time-arithmetic” ) 

Section  6  *** 

Apply-lemma  strategies  for  timed  automata.  *** 


;  Some  of  the  apply-lemma  strategies  are  specialized  for  application  of  state  invariant  lemmas. 

(defstep  apply  Jemma  (lem  args) 

(let  ((x  (cons  ’inst  (cons  —1  args)))) 

(then  (lemma  lem)  x)) 

“”  “Applying  a  lemma  to  some  arguments”) 

(defstep  apply Jnv Jemma  (invno  feoptional  statevar) 

(let  ((lemmajiame  (format  nil  “-a -a”  “lemma.”  invno)) 

(theoremmame  (format  nil  “  ~a ~a”  “lemma.”  invno)) 

(invjiame  (format  nil  “-a -a”  “Inv.”  invno)) 

(state  (cond  (statevar)  (t  “s_l”)))) 

(then*  (try  (apply  Jemma  lemma  .name  (state))  (skip) 

(apply Jemma  theorem_name  (state))) 

(assert) 

(expand  inv_name))) 

“”  “Applying  the  appropriate  invariant  lemma” ) 

(defstep  apply.univ  Jnv  Jemma  (invno  quantvar  ^optional  statevar) 

(let  ((lemma_name  (format  nil  “~a~a”  “lemma.”  invno)) 

(theorem_name  (format  nil  “~a~a”  “lemma.”  invno)) 

(invjiame  (format  nil  “~a~a”  “Inv.”  invno)) 
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*** 

*** 


(state  (cond  (statevar)  (t  “s_l”)))) 

(then*  (try  (apply Jemma  lemma_name  (state))  (skip) 

(apply Jemma  theorem_name  (state))) 

(assert) 

(expand  inv_name) 

(inst  -1  quantvar))) 

“Applying  the  appropriate  invariant  lemma”) 

Section  7 

General  strategies  useful  in  reasoning  about  atexecs. 


;  The  strategy  put-gib  finds  the  time  index  of  the  last  indexed  time  in  an  atexec  that  is  less  than  or  equal 
;  to  the  particular  non-negative-real  valued  bound  “timebound”,  and  gives  it  an  associated  name. 

(defstep  put-gib  (atexec  timebound) 

(let  ((x  (format  nil  “~a~a”  timebound  “-gib”)) 

(y  timebound) 

(z  atexec)) 

(put_glb-2  x  y  z)) 

(defstep  put_glb_2  (boundname  timebound  atexec) 

(let  ((x  (list  atexec  timebound)) 

(y  (list  boundname))) 

(then  (apply Jemma  “glbJact”  x)  (skolem  —1  y)  (flatten))) 

;  The  strategy  get_reachables  adduces  the  fact  of  reachability  for  states  in  an  atexec  near  time  index  “index” , 
;  under  various  aliases. 

(defstep  get_reachables  (atexec  index) 

(let  ((x  (list  atexec  index))) 

(then  (apply Jemma  “reachable jstates”  x)  (flatten))) 

;  The  strategy  trans  Jacts  adduces  the  relatedness  of  states,  under  various  aliases,  via  a  transition  in  an 
;  atexec  near  time  index  “index” . 

(defstep  trans  Jacts  (atexec  index) 

(let  ((x  (list  atexec  index))) 

(then  (apply Jemma  “trans  Jacts”  x) 

(flatten)  (assert)  (flatten))) 

tt 5)  U?J  ^ 

;  The  strategy  normalize_atexecs  converts  all  time  points  and  state  points  of  an  admissible  timed  execution 
;  to  a  normal  form,  so  that  equalities  may  be  inferred. 

(defstep  normalize^atexecs  () 

(then  (auto-rewrite-theory  “opspecjstrat_aux”) 

(apply  (do-rewrite))) 

;  The  strategy  time.order  is  used  to  infer  an  inequality  between  time  indices  from  the  same  inequality 
;  between  the  indexed  times. 

(defstep  time_order  (atexec  nl  n2) 

(let  ((x  (list  atexec  nl  n2))) 

(then  (apply Jemma  “time-relation”  x)  (flatten)  (simplify))) 
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;  The  strategy  match-condition  is  used  to  simplify  reasoning  about  an  IF-THEN-ELSE  assertion.  It  can 
;  sometimes  circumvent  splitting;  when  it  does  not,  it  can  make  the  result  of  splitting  more  “natural”. 

(defstep  match-condition  (fnum) 

(then  (split  fnum)  (flatten)  (assert)) 

“Attempting  to  eliminate  a  condition”) 

The  strategy  modus.ponens  is  used  to  avoid  splitting  an  assertion  having  a  complex  hypothesis  identical 
to  another  assertion  present. 

(defstep  modus_ponens  (fnum) 

(branch  (split  fnum)  ((skip)  (assert))) 

“”  “Attempting  to  eliminate  an  hypothesis”) 

***  Section  8  *** 

***  A  special  tcc  strategy.  *** 

A  strategy  useful  in  proving  the  tecs  for  the  lemmas  about  admissible  timed  traces  used  to  support 
normalize_atexecs: 

(defstep  same_states_tcc  (atexec  leftend  rightend) 

(let  ((timeseq  (format  nil  “~a,~a~a”  “t(”  atexec  “)”)) 

(trajseq  (format  nil  “~a~a~a”  “w(”  atexec  “)”))) 

(then  (skosimp) 

(expand  “interval”) 

(apply  (then  (typepred  atexec)  (hide  —1—3  —4)  (inst-cp  —1  leftend) 

(inst  —1  rightend))) 

(apply  (then  (typepred  timeseq)  (hide  —1)  (inst  —1  leftend  rightend))) 

(apply  (then  (typepred  trajseq)  (inst  —1  leftend))) 

(expand  “ltime”) 

(assert))) 

***  Section  9  *** 

***  Strategies  for  the  timed.auto  template  version.  *** 


(defstep  auto_proof_opspec_timed_auto  (inv) 

(then  (branch  (time  (auto.cases  inv)) 

(then  (base_case_timed-auto  inv) (opspec_simp_probe) (postpone)) 
(branch  (induct .cases  inv) 

((then  (reduce_case_timed_auto_one_var_exp  inv  “t_l”) 
(opspec_simp_probe)  (postpone)) 

(then  (reduce_case-timed-auto-one_var_exp  inv  “rJ”) 
(opspec-simp.probe)  (postpone) ) 

(then  (reduce.case_timed_auto_one_var_exp  inv  “r_l”) 
(opspec-simp  .probe)  (postpone) ) 

(then  (reduce_case_timed_auto_one_var_exp  inv  “r_l”) 
(opspec_simp_probe)(postpone)) 

(then  (reduce.case_timed-autojno_var.exp  inv) 
(opspec-simp_probe)  (postpone) ) 

(then  (reduce_case_timed_auto_no_var_exp  inv) 
(opspec_simp  .probe)  (postpone) ) 

(then  (reduce_case_timed_auto_no_var_exp  inv) 
(opspec_simp_probe)  (postpone)) 

(then  (reduce_case_timed_auto_no_var_exp  inv) 
(opspec-simp.probe)  (postpone) )))))) 

“Taking  care  of  the  standard  steps  in  the  proof’ ) 
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(defstep  base_case_timed_auto  (inv) 

(then*  (delete  2) 

(expand  “base”) 

(skolem  1  “s_l”) 

(flatten) 

(expand  “start”) 

(flatten) 

(expand  “basic jstart” ) 

(expand  inv)) 

“Simplifying  the  auto  base  case” ) 

(defstep  reduce_case_timed_auto_one_var_exp  (inv  varl) 

(then*  (delete  2) 

(skolem  1  (varl)) 

(skolem  1  (“s.l”)) 

(flatten) 

(expand  “enabled”) 

(expand  “trans”) 

(expand  “basic.trans” ) 

(expand  inv)) 

“”  “Applying  the  standard  simplification”) 

(defstep  reduce_case_timed_auto_no_var_rew  (inv) 

(then*  (delete  2) 

(skolem  1  (“s_l”)) 

(flatten) 

(rewrite  “enabled”) 

(rewrite  “trans”) 

(expand  “basic.trans”) 

(expand  inv)) 

“”  “Applying  the  standard  simplification”) 

(defstep  reduce_case_timed_auto_no_var_exp  (inv) 

(then*  (delete  2) 

(skolem  1  (“s.l”)) 

(flatten) 

(expand  “enabled”) 

(expand  “trans”) 

(expand  “basic.trans”) 

(expand  inv)) 

“”  “Applying  the  standard  simplification”) 

(defstep  normalize_atexecs .timed _auto  () 

(then  (auto-rewrite-theory 

“timed_auto_thy  [  basic_states,  actions,  nu,  nu?,  timeof,  basic_start, 
first-start,  last_start,  basic.trans,  first.trans, 
basic.trans,  enabled  specific,  OKstate?]”) 

(apply  (do-rewrite))) 

(defstep  do-trans.opspec.timed.auto  () 

(then  (expand  “trans”) 

(expand  “basic-trans” ) (expand  “first.trans”) (expand  “last.trans” ) 
(opspec-simp)  (lift-if )  (assert)  (assert) ) 


55 


D  Appendix.  PVS  Proofs  of  State  Invariants 

In  this  Appendix,  we  present  our  PVS  proofs  of  all  the  state  invariants  that  we  have  proved  for  our  timed 
automata  models.  With  the  exceptions  noted,  these  proofs  all  follow  this  standard  script: 

•  If  the  proof  is  an  induction  proof,  apply  the  appropriate  induction  strategy;  otherwise,  apply  the  appro¬ 
priate  direct-proof  strategy. 

•  For  each  generated  subgoal,  introduce  the  facts  and  case  splits  appealed  to  in  the  hand  proof.  The  facts 
appealed  to  may  be  the  transition  precondition  (if  the  subgoal  is  an  action  case  in  the  induction  proof), 
axioms  about  constants  in  the  automaton  definition,  applications  of  invariant  lemmas,  or  applications  of 
other  lemmas. 

•  Attempt  to  complete  the  proof  with  an  appeal  to  the  strategy  TIMEJETCJSIMP. 

•  In  cases  where  this  fails — often,  these  are  cases  dismissed  as  trivial  in  the  hand  proof — appeal  to  one  of  the 
following:  the  precondition,  an  appropriate  uniqueness  lemma,  or  facts  about  the  constants  associated 
with  the  timed  automaton.  Then  again  call  TIME_ETC_SIMP. 

Below  is  the  proof  of  the  single  state  invariant  for  the  timed  automaton  Trains .  It  follows  the  standard 
script. 


trains  Jnvariants  .lemma  JL1 : 

(“”  (AUTOJPROOF.UNIVJTRAINS  “Inv_3.1”) 

((“1”  (APPLY  (TIME_ETC_SIMP)  “Case  enterR(r.l)  ”)) 

(“2”  (APPLY  (THEN  (APPLY_LEMMA  “enterLunique”  (“rJL”  “r_2”))  (TRAINS  JSIMP)) 
“Case  enterl(rJL).”) 

(TIMEJETC.SIMP)))) 


Below  are  the  proofs  of  the  seven  state  invariants  for  the  timed  automaton  OpSpec.  All  of  these  proofs 
follow  the  standard  script. 


opspec  jnvariants. lemma_4_lJ.: 

(“”  (AUTO_PROOF_OPSPEC  tTnv_4.1_l”)) 


opspecJnvariants.lemma_4_l_2: 

(“”  {AUTO-PROOF_OPSPEC  “Inv_4_l_2”) 

((“1”  (APPLY  (TIMEJETCJSIMP)  “Base  case.”  “Infinity  plus  finite  equals  infinity.”)) 

(“2”  (APPLY  (TIMEJETCJSIMP)  “Case  enterl(r.l).”  “Infinity  plus  finite  equals  infinity.”)) 
(“3”  (APPLY  (TIMEJETCJSIMP)  “Case  up.”  “Infinity  plus  finite  equals  infinity.”)))) 


opspec  Jnvariants.lemma-4_2_1 : 


(“”  (AUTO_PROOF_OPSPEC  “Inv_4_2_l”) 

((“1”  (APPLY  (TIME.ETCJSIMP)  “Base  case.”  “zero  <=  infinity.”)) 

(“2”  (APPLY  (THEN  (EXPAND  “enabled-specific” )  (OPSPEC J3IMP))  “Case  nu(t_l).”)) 
(“3”  (APPLY  (TIME_ETCJSIMP)  “Case  enterl(rJL).”  “finite  <=  infinity.”)) 

(“4”  (APPLY  (TIME JSTC JSIMP )  “Case  lower.”  “a  <=  a  +  b .”)))) 


opspec  Jnvariants.lemma_4_2_2: 

(“”  (AUTOJPROOF_OPSPEC  “Inv_4_2_2”) 

((“1”  (APPLY  (TIMEJETCJSIMP)  “Base  case.”  “Finite  <=  infinity.”)) 
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(“2”  (APPLY  (THEN  (EXPAND  “enabled_specific” )  (OPSPECJSIMP))  “Case  nu(t.l).”)) 
(“3”  (APPLY  (TIME_ETCJSIMP)  “Case  enterl(r.l).”  “Finite  <=  infinity.”)) 

(“4”  (APPLY  (TIME-ETC-SIMP)  “Case  exit.”  “a  <=  a  +  b  +  c  +  d.”)) 

(“5”  (APPLY  (TIME-ETC-SIMP)  “Case  up.”  “Finite  <=  infinity.”)))) 

opspec  invariants.lemma_4_2_3: 

(“”  (AUTO-PROOF-OPSPEC  “Inv_4-2.3”) 

((“1”  (APPLY  (TIME-ETC-SIMP)  “Case  nu(t-l)  ”  “Finite  <=  infinity.”)) 

(“2”  (APPLY  (TIME-ETC.SIMP)  “Case  lower.”  “a  <=  a.”)))) 

opspec  invariants.lemma_4_2_4: 

(“”  (AUTO-PROOF-OPSPEC  “Inv_4_2_4”) 

((“1”  (APPLY  (TIME-ETC.SIMP)  “Case  nu(t-l).”  “Finite  <=  infinity.”)) 

(“2”  (APPLY  (TIMEJETC-SIMP)  “Case  exit(r-l).”  “a  <=  a.”)))) 

opspec-invariants.lemma-4_2_5: 

(“”  (AUTO_PROOF-OPSPEC  “Inv-4-2.5”) 

((“1”  (APPLY  (TIME.ETC-SIMP )  “Case  nu(t.l)”  “a  <=  b  +  c  implies  a  <=  b  +  d  +  c.”)) 
(“2”  (APPLY  (TIME-ETC-SIMP)  “Case  exit (r.l) .”  “a  <=  a.”)))) 


Below  are  the  proofs  of  the  thirteen  invariant  lemmas  of  the  timed  automaton  Systlmpl.  The  ones  whose 
proofs  differ  from  the  standard  script  are  lemma-6-1  and  lemma-6-3. 

The  major  differences  in  lemma-6 _3,  which  is  logically  equivalent  to  lemma-6 _3_A,  result  from  the  fact 
that  it  is  formulated  with  an  embedded  existential  quantifier  rather  than  a  top-level  universal  quantifier, 
making  it  difficult  to  predict  how  to  match  skolemization  and  instantiation  in  the  induction  steps.  The 
differences  in  lemma-6-1  consist  of  uses  of  MODUS-PONENS,  ASSERT,  and  INST.  MODUS-PONENS  is 
used  to  eliminate  from  some  implication-assertions  their  hypotheses  that  would  have  been  eliminated  by 
the  calls  to  ASSERT  in  the  apply-invariant-lemma  strategies  if  they  had  been  simpler  in  form.  The  call 
to  ASSERT  then  eliminates  another  hypothesis  that  was  the  conclusion  of  one  of  the  original  implication- 
assertions;  combining  it  with  INST  accomplishes  the  required  instantiation  of  part  of  the  precondition  of  the 
action  nu(t_l). 

With  appropriate  enhancements  to  PVS,  these  deviations  from  the  standard  script  can  be  eliminated, 
except  possibly  for  the  “appropriate  instantiation  of  the  precondition” ;  whether  this  step  can  be  automated 
as  part  of  a  general  apply-the-precondition  strategy  remains  to  be  determined. 


sy  stimpl  -invariants  .lemma-5  _1 .1 : 

(“”  (AUTOJPROOF-UNIV-SYSTIMPL  “Inv-5-l_l”) 

((“1”  (APPLY  (TIME-ETC-SIMP)  “Base  case.” 

“Retrieving  function  defs  from  state  s.l  and  doing  beta  reduction.”)) 

(“2”  (APPLY  (THEN  (EXPAND  “enabled-specific”)  (SYSTIMPL-SIMP))  “Case  enterl(r-l).”) 
(TIME-ETC-SIMP)))) 


systimpl invariants  .lemma-5 _1  -2 : 

(“”  (AUTO-PROOF_UNIV_SYSTIMPL  “Inv.5-1-2”) 

((“1”  (APPLY  (APPLY.LEMMA  “enterLunique”  (“r.l”  “r_2”))  “Case  enterR(r.l)).”) 
(TIME_ETC-SIMP)) 

(“2”  (APPLY  (APPLY-LEMMA  “enterLunique”  (“rJL”  “r_2”))  “Case  enterl(r.l).”) 
(TIME_ETC-SIMP)))) 
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systimpl  Jnvariants.lemma_5_1.3: 


(“”  (AUTO-PROOF.UNIV.SYSTIMPL  “Inv_5_l_3”) 

((“1”  (APPLY  (TIME-ETC.SIMP)  “Case  nu(t.l).”  “a  >  b  +  c  implies  a  >  b.”)) 

(“2”  (APPLY  (THEN  (EXPAND  “enabled specific”)  (SYSTIMPL_SIMP))  “Case  enterl(r.l).”) 
(APPLY  (THEN  (APPLY.UNIVJNV-LEMMA  “5-1.2”  “r.l”)  (SYSTIMPL.SIMP))) 
(APPLY  (TIME-ETC.SIMP)  “Doing  obvious  case-based  reasoning.”)))) 


systimpl  Jnvariants.lemma.5-1-4: 


(“”  (DIRECT-PROOF.UNIV-SYSTIMPL  “Inv-5.1.4”) 

(APPLY  (THEN  (APPLY.UNIVJNV.LEMMA  “5.1.1”  “r_l”)  (SYSTIMPLJSIMP))) 
(APPLY  (THEN  (APPLY .UNIV.INV.LEMMA  “5.1.3”  “r.l”)  (SYSTIMPLJSIMP))) 
(TIME.ETC-SIMP)) 


systimpl  Jnvariants.lemma.5.1.5: 


(“”  (AUTOJPROOF.UNIV.SYSTIMPL  “Inv.5.1.5”)) 


systimpl  Jnvariants.lemma.5 .2.1 : 

(“”  (AUTO.PROOFJ3YSTIMPL  “Inv.5-2.1”) 

((“1”  (APPLY  (THEN  (EXPAND  “enabled specific”)  (SYSTIMPLJSIMP))  “Case  up.”) 
(TIMEJDTC.SIMP)) 

(“2”  (APPLY  (THEN  (EXPAND  “enabled specific”)  (SYSTIMPLJSIMP))  “Case  down.”) 
(TIME2ETC.SIMP)))) 


systimpl  .invariants. lemma.5  .2  .2: 


(“”  (DIRECT JPROOF.UNIVJSYSTIMPL  “Inv_5_2_2”) 

(APPLY  (THEN  (APPLY _INV_LEMMA  “5.2.1”)  (SYSTIMPL.SIMP))) 
(TIME-ETC.SIMP)) 


systimpl  Jnvariants.lemma-B.1.1: 

(“”  (AUTO-PROOF.SYSTIMPL  “InvJB.1.1”) 

((“1”  (APPLY  (THEN  (EXPAND  “enabled specific”)  (SYSTIMPL.SIMP))  “Case  nu(t.l).”) 
(APPLY  (HIDE  —5  —8  —9)  “Hiding  quantified  formulae  before  using  (time .etc .simp).”) 
(APPLY  ( T I M E _E  I C _S  1 M P )  “Doing  time-arithmetic:  reversing  an  inequality.”)) 

(“2”  (APPLY  (TIMEJETC.SIMP)  “Case  lower.” 

“Doing  propositional  reasoning  plus  time  arithmetic.”)))) 


systimpl  Jnvariants. lemma  JB  .1 .2 : 

(“”  (AUTOJPROOFJ3YSTIMPL  “InvJB.1.2”) 

((“1”  (APPLY  (TIME.ETC-SIMP)  “Case  nu(t.l).”)) 
(“2”  (APPLY  (TIME.ETC-SIMP)  “Case  lower.”)))) 


systimpldnvariants. lemma.6.1: 

(“”  ( AUTO .PROOF.UNIV .SYSTIMPL  “Inv.6.1”) 

((“1”  (APPLY  (THEN  (EXPAND  “enabled .specific”)  (SYSTIMPL.SIMP)) 
“Case  nu(t.l).  Invoke  the  precondition.”) 

(APPLY  (THEN  (APPLY JNV.LEMMA  “5.2.1”)  (SYSTIMPL.SIMP))) 
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(APPLY  (THEN  ( APPLY-UNIV JN V.LEMM A  “5-1-2”  “r.2”)  (SYSTIMPL-SIMP))) 
(MODUS.PONENS  -3) 

(MODUS.PONENS  -5) 

(ASSERT) 

(INST  -11  “r_2” ) 

(APPLY  (HIDE  -8)  “Hiding  quantified  formulas.”) 

(TIME-ETC-SIMP)) 

(“2”  (APPLY  (THEN  (APPLY -LEMMA  “const-facts”  NIL) 

(APPLY-LEMMA  “enterLunique”  (“r_l”  “r_2”))) 

“Case  enterR(r.l).  Appeal  to  some  standard  facts.”) 

(APPLY  (TIME.ETC-SIMP)  “Combine  some  propositional  and  time-arithmetic  reasoning.”)) 
(“3”  (APPLY  (APPLY-LEMMA  “enterLunique”  (“r.l”  “r.2”)) 

“Case  enterl(r_l).  Appeal  to  some  standard  facts.”) 

(TIME-ETC.SIMP)) 

(“4”  (APPLY  (THEN  (EXPAND  “enabled specific”)  (SYSTIMPL.SIMP)) 

“Case  raise.  Invoke  the  precondition.”) 

(INST  1  “r-2”) 

(APPLY  (THEN  ( APPLY-UNIV  JNV.LEMMA  “5.1.2”  “r.2”)  (SYSTIMPL-SIMP) )) 
(TIME-ETC-SIMP)) 

(“5”  (APPLY  (THEN  (EXPAND  “enabled-specific”)  (SYSTIMPL-SIMP)) 

“Case  up.  Invoke  the  precondition.”) 

(APPLY  (TIME.ETCJSIMP)  “Applying  simple  propositional  reasoning.”)))) 


systimpl  Jnvariants.lemma.6-2 : 

(“”  (AUTO_PROOF_UNIV_SYSTIMPL  “Inv.6-2”) 

((“1”  (APPLY  (THEN  ( APPLY  JNV-LEMMA  “B.1.2”)  (SYSTIMPL-SIMP))  “Case  enterR(r.l).”) 
(APPLY  (APPLYJLEMMA  “const-facts”  NIL)  “Appealing  to  some  standard  facts.”) 
(APPLY  (TIMEJBTC-SIMP)  “Combining  reasoning  about  cases  and  time  arithmetic.”)) 

(“2”  (APPLY  (APPLY-LEMMA  “enterLunique”  (“r.l”  “r.2”))  “Case  enterl(r.l).” 

“Appealing  to  a  standard  fact.”) 

(APPLY  (TIME.ETC-SIMP)  “Doing  some  propositional  reasoning.”)) 

(“3”  (APPLY  (THEN  (APPLY.UNIVJNVXEMMA  “6.1”  “r_2”)  (SYSTIMPL-SIMP)) 

“Case  lower.”  “Apply  invariant  lemma  6_1.”) 

(APPLY  (TIME-ETC-SIMP)  “Doing  propositional  reasoning  by  cases.”)))) 

systimplinvariants.lemma-6-3: 

(“”  (APPLY  (AUTO-PROOF .SYSTIMPL  “Inv.6.3”)  “Use  induction”) 

((“1”  (APPLY  (TIME_ETC_SIMP)  “Case  enterR(r.l).” 

“Prepare  sequent  for  matched  SKOLEM  and  INST.”) 

(APPLY  (THEN  (SKOLEM  -4  “r.2”)  (INST  1  “r_2”))  “Setting  r  =  r_2”) 

(APPLY  (TIME-ETC-SIMP)  “Confirm  that  this  case  is  trivial.”)) 

(“2”  (APPLY  (TIMEJETC-SIMP)  “Case  enterl(r_l).” 

“Prepare  sequent  for  matched  SKOLEM  and  INST.” ) 

(APPLY  (THEN  (SKOLEM  -4  “r-2”)  (INST  1  “r.2”))  “Setting  r  =  r.2.”) 

(APPLY  (THEN  (EXPAND  “enabled_specific” )  (SYSTIMPL-SIMP)) 

“Invoke  the  precondition.”) 

(CASE  “gate-status(s.l)  =  fully _up  or  gate_status(s-l)  =  going_up”) 

((“1”  (APPLY  (THEN  (APPLY.UNIV.INVXEMMA  “6.1”  “r.l”)  (SYSTIMPL-SIMP)) 
“Invoke  the  invariant  lemma  6-1.”) 

(APPLY  (TIME_ETC-SIMP)  “Derive  contradiction  with  the  precondition.”)) 

(“2”  (APPLY  (THEN  (APPLY _UNIV_INV_LEMMA  “6-2”  “r.l”)  (SYSTIMPL-SIMP)) 
“Invoke  the  invariant  lemma  6.2.”) 
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(APPLY  (THEN  (APPLY  JNV.LEMMA  “B_l_l”)  (SYSTIMPLJSIMP)) 

“Invoke  the  invariant  lemma  B.l,  part  1.”) 

(APPLY  (TIME_ETC_SIMP)  “Derive  contradiction  with  the  precondition.”)))) 

(“3”  (APPLY  (TIME.ETC-SIMP)  “Case  exit(r.l).” 

“Prepare  sequent  for  matched  SKOLEM  and  INST.” ) 

(APPLY  (THEN  (SKOLEM  -4  “r.2”)  (INST  1  “r.2”))  “Setting  r  =  r.2.”) 

(APPLY  (TIMEJETC.SIMP)  “Confirm  that  this  case  is  trivial.”)) 

(“4”  (APPLY  (TIME-ETC.SIMP)  “Case  raise”) 

(APPLY  (THEN  (SKOLEM  -5  “r_2”)) 

“Matching  formula  for  INST  was  eliminated.  Setting  r  =  r_2.”) 

(APPLY  (THEN  (EXPAND  “enabled .specific” )  (SYSTIMPLJ3IMP)  (INST  1  “r_2”)) 
“Invoke  and  specialize  the  pre-condition.”) 

(APPLY  (THEN  (APPLY.UNIVJNV.LEMMA  “5.1.1”  “r.2”)  (SYSTIMPL.SIMP)) 
“Invoke  invariant  lemma  5.1,  part  1.”) 

(APPLY  (THEN  (APPLY.UNIVJNV.LEMMA  “5.0”  “r_2”)  (SYSTIMPLJSIMP)) 

«■  “Invoke  invariant  lemma  5.1,  part  3.”) 

(APPLY  (TIME-ETC.SIMP)  “Derive  contradiction.”)) 

4“5”  (APPLY  (THEN  (EXPAND  “enabled-specific”)  (SYSTIMPL.SIMP)) 

“Case  up.  Invoke  the  precondition.”) 

(APPLY  (TIME _ETC_SIMP)  “Derive  contradiction  with  the  precondition.”)))) 
systimplJnvariants.lemma_6.3-A: 

(“”  (APPLY  (AUTO-PROOF.UNIV.SYSTIMPL  “Inv_6_3.A”)  “Use  induction.  Fix  r  =  r_2.”) 

((“1”  (APPLY  (THEN  (EXPAND  “enabled specific”)  (SYSTIMPL.SIMP)) 

“Case  enterl(r.l).  Invoke  the  precondition.”) 

(CASE  “gate-status(s.l)  =  fully  .up  OR  gate_status(s_l)  =  going.up”) 

((“1”  (APPLY  (THEN  (APPLY  JJNIVJNVJJEMMA  “6.1”  “r.l”)  (SYSTIMPLJSIMP)) 
“Invoke  the  invariant  lemma  6.1.”) 

(APPLY  ( T I M E . E T C _S I M P )  “Derive  contradiction  with  the  precondition.”)) 

(“2”  (APPLY  (THEN  (APPLY.UNIVJNV-LEMMA  “6.2”  “r.l”)  (SYSTIMPLJSIMP)) 
“Invoke  the  invariant  lemma  622.” ) 

(APPLY  (THEN  ( APPLY  JNV .LEMMA  “B.1.1”)  (SYSTIMPLJSIMP)) 

“Invoke  invariant  lemma  B.l,  part  1.”) 

(APPLY  (TIME -ETC.SIMP)  “Derive  contradiction  with  the  precondition.”)))) 

(“2”  (APPLY  (THEN  (EXPAND  “enabled-specific”)  (SYSTIMPLJSIMP)  (INST  1  “r_2”)) 
“Case  raise.  Invoke  and  specialize  the  precondition.”) 

::  (APPLY  (THEN  (APPLY.UNIVJNV.LEMMA  “5.1.1”  “r_2”)  (SYSTIMPLJSIMP)) 

“Invoke  invariant  lemma  5.1,  part  1.”) 

(APPLY  (THEN  (APPLYJJNIVJNV-LEMMA  “5.0”  “r_2”)  (SYSTIMPLJSIMP)) 
“Invoke  invariant  lemma  5.1,  part  3.”) 

(APPLY  (TIME-ETC.SIMP)  “Derive  contradiction.”)) 

(“3”  (APPLY  (THEN  (EXPAND  “enabled-specific” )  (SYSTIMPLJSIMP)) 

“Case  up.  Invoke  the  precondition.”) 

(APPLY  (TIMEJETC-SIMP)  “Derive  contradiction  with  the  precondition.”)))) 
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E  Appendix.  Lessons  from  the  PVS  Proof  of  Lemma  E.l 

In  the  first  section  of  this  Appendix,  we  present  the  statement  of  Lemma  E.l  from  Appendix  B.3  of  [12], 
and  its  proof  in  PVS,  annotated  by  an  equivalent  interleaved  English  language  proof.  The  PVS  proof  was 
developed  as  follows:  First,  an  attempt  was  made  to  follow  the  hand  proof  in  [12]  as  closely  as  possible. 
Many  missing  details  needed  for  the  PVS  prover  were  incorporated  in  this  proof,  resulting  in  a  PVS  proof 
running  to  over  6  pages,  not  counting  comments.  Strategies  were  designed  to  abbreviate  many  of  the  repeated 
sequences  in  reasoning;  these  sequences  were  identified  by  the  purpose  they  served,  and  were  therefore  not 
always  precisely  syntactically  isomorphic.  The  proof  was  then  redone  using  the  new  strategies  to  replace 
longer  sequences.  At  this  stage,  the  structure  of  the  PVS  proof  became  much  clearer,  and  it  was  possible  to 
eliminate  duplicated  efforts  and  simply  wasteful  steps.  Comments  were  incorporated  with  the  proof  steps  to 
help  clarify  this  structure.  The  resulting  PVS  proof  was  then  annotated  in  fuller  detail  in  English. 

Note  that  this  is  not  the  method  by  which  we  expect  other  ad  hoc  timed  automaton  proofs  in  PVS  to  be 
developed.  One  result  of  our  study  of  such  proofs  should  be  the  identification  of  parts  of  English  language 
proofs  that  need  additional  detail  to  be  added  when  translated  for  the  automatic  prover,  as  well  as  the  type 
of  additional  detail  they  need.  With  this  knowledge,  a  hand  proof  can  be  expanded  to  a  more  detailed  one 
more  suitable  for  straightforward  translation.  Used  in  combination  with  the  more  sophisticated  large  step 
strategies  whose  development  will  become  possible  when  appropriate  enhancements  are  added  to  PVS,  this 
approach  can  bring  us  closer  to  the  ideal  of  mimicking  a  natural  hand  proof  in  PVS.  The  addition  to  PVS 
of  a  facility  for  attaching  comments  to  goals  rather  than  proof  steps  will  also  aid  in  the  documentation  of 
the  correspondence  between  natural  language  proof  and  PVS  proof. 

Included  among  our  annotations  of  the  Lemma  E.l  proof  are  indications  of  step  sequences  that  have  the 
potential  of  being  replaced  by  calls  to  large  step  strategies  supported  by  PVS  enhancements.  These  sequences 
are  denoted  by  asterisks  along  the  right  margin,  with  number  tags  in  the  form  (m.n),  where  m  denotes  the 
m-th  potential  strategy,  and  n  denotes  the  n-th  place  where  this  strategy  could  be  used.  The  second  section 
of  this  Appendix  describes  the  desired  effects  and  possible  implementations  of  these  strategies,  and  shows 
for  each  potential  use  just  how  the  strategy  might  be  invoked. 

E.l  The  PVS  Proof  of  Lemma  E.l  with  Annotations 


;  Lemma_E_l:  Let  alpha  be  an  admissible  timed  execution  of  OpSpec.  Let  Pi  be  any  lower  event 
;  occurring  in  alpha  from  a  state  in  which  Gate.status  is  in  {going-up,  up}.  Then  there  is  an  enterl 
;  event  Phi  occurring  after  Pi  in  alpha,  with  time(Phi)  <=  time(Pi)  +  xLl. 

;  Let  A-l  be  an  atexec  of  OpSpec  and  n_l  be  the  index  of  the  action  Pi  =  pi(A_l)(n.l),  which  occurs 
;  from  the  state  lstate(w(A.l)(n.l  -  1))  in  which  the  gate  is  either  going.up  or  fully  .up. 

(SKOLEM  1  “A.l”) 

(SKOLEM  1  “n.l” ) 

(FLATTEN) 

;  For  convenience,  we  will  call  the  state  just  before  Pi,  namely  lstate(w(A_l)(n_l  —  1)),  s.l,  and  the 
;  state  after  Pi,  namely  fstate(w(A.l)(n_l)),  s_2. 

(APPLY  (THEN  (NAME  “s.l”  “lstate(w(A.l)(n.l  -  1))”) 

(NAME  “s_2”  “fstate(w(A_l)(n.l))”)) 

“Give  names  s.l  and  s.2  to  the  states  just  before  and  after  Pi.”) 

;  Supposition  1:  The  time  of  Pi,  t(A.l)(n_l),  equals  now(s.l)  and  now(s.2). 

(APPLY  (CASE  “now(s_2)  =  now(s.l)  &  Now(s.l)  =  t(A.l)(n.l)”) 

“Assume  the  time  equivalences  from  the  first  sentence  of  the  hand 
proof.  The  proof  of  these  facts  below  depends  mainly  on 
normalize  jrtexecs.” ) 

((“1” 


61 


;  Supposition  2:  iast_l(s_2)  <—  now(s_2)  -f  xi_l. 

(APPLY  (CASE  “last_l(s_2)  <=  now(s_2)  4-  xLl”) 

“Assume  the  inequality  that  concludes  the  first  paragraph  of  the 
hand  proof.  It  will  be  proved  later  below.”) 

((“i” 

(TIME-SIMP  -1) 

(FLATTEN) 

;  Call  the  value  last_l(s_2),  b. 

(NAME  “b”  “dur(last_l(s_2))”) 

(APPLY  (REPLACE  -1)  “Using  the  name  b.” 

“Note  that  it  would  be  helpful  to  have  a  general  strategy 
replace_names  that  could  periodically  be  invoked  to  call 
replace  on  all  definitions  entered  via  NAME,  and  perhaps 
certain  others.  Marked  definitions  could  be  kept  hidden 
until  recalled  for  this  purpose  or  for  a  general  review 
of  definitions.”) 

;  Call  the  value  t(A_l)(n_l)  +  dur(xLl),  B. 

(NAME  “B”  “t(A_l)(n_l)  4*  dur(xLl)”) 

;  Let  B_glb  name  the  largest  index  for  which  t(A-l)(B_glb)  <=  B. 

(PUT.GLB  “ALL”  “B”) 

;  Supposition  3:  B_glb  +  1  >  n_l. 

(CASE  “B-glb  4-  1  >  n_l”) 

((“1” 

;  Note  that  part  of  the  hypothesis  of  lemma_E-l  is  that  the  gate  is  either  goingjup  or  fully_up  in  state  s_l. 

(NORM  ALIZE^ATEXECS) 

(REPLACE  -11) 

;  Supposition  A(B):  We  suppose  something  that  appears,  a  priori,  stronger  than  the  negation  of  what 
;  we  hope  to  prove,  in  order  to  derive  a  contradiction:  namely,  that  there  is  no  enterl  event  from  event 
;  Pi  to  time  B,  *and*  that  the  last_l  component  of  the  state  after  every  event  from  Pi  to  B  has  the 
;  same  value  last_l(s_2).  Actually,  the  second  part  is  redundant,  but  is  needed  in  the  induction  proof 
;  that  comes  later. 

;  We  actually  state  this  supposition  in  a  more  complex  form.  This  more  complex  form  of  Supposition 
;  A(B)  says  that  every  event  from  the  n_l-th  event  Pi  to  time  B  has  property  A,  where  property  A  of 
;  any  m-th  event  is  that  every  p-th  event  from  event  Pi  through  that  m-th  event  has  property  A-hat: 

;  namely,  it  is  not  an  enterl  event  and  the  last_l  component  of  its  result  state  equals  last  LL(s_2). 

(APPLY  (CASE  “(forall  (m:pos_nat):  (m  >=  nLL  &  t(A_l)(m)  <=  B)  => 

—  (forall  (p:pos_nat):  ((n_l  <=  p  &  p  <—  m)  => 

(not  (exists  (r:  train):  pi(A_l)(p)  =  enterl(r))  & 
last_l(fstate(w(A_l)(p)))  =  last_l(s_2)))))”) 

“Call  this  assertion  A(B).  We  hope  it  is  not  true.  Thus,  we 
expect  to  obtain  a  contradiction  by  assuming  it.  It  says, 
in  effect,  that  every  event  before  and  up  to  time  bound  B 
is  the  last  in  a  chain  of  events  starting  with  Pi  that  have 
the  same  last  _1  value  when  they  occur,  and  that  are  not  an 
enterl.”) 

((“i” 

;  In  particular,  event  B-glb  has  property  A. 

(INST  -1  “B-glb”)  * 

((“1”  *  (1.1) 

(ASSERT)  * 
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;  So,  event  B_glb  has  property  A-hat. 

(APPLY  (INST  -1  “B_glb”)  * 

“Starting  to  show  that  last_l  still  has  the  value  it  did  * 

at  s_2  when  the  B-glb-f  1-th  event  occurs.  This  uses  the  * 

fact  that  time  has  advanced  beyond  B,  in  a  hidden  way —  *  (1.2) 

via  lemma  last _1  interval .  It  will  lead  to  a  contradiction.”)  * 

(ASSERT)  * 

(FLATTEN)  * 

;  Let  s_3  name  the  state  just  after  the  B_glb-th  event,  and  s_4  name  the  state  just  before  the 
;  (B_glb  4-  l)-th  event. 

(APPLY  (THEN  (NAME  “s_3”  “fstate(w(A-l)  (B-glb))”) 

(NAME  “s_4”  “lstate(w( A_l) (B_gib))” )) 

“Let  s_3  and  s_4  be  the  left  and  right  endpoints  of  the 
B_glb-th  interval,  which  spans  the  time  B.”) 

;  A  standard  lemma  says  that  components  of  the  state  other  than  the  “now”  component  are  not 
;  affected  by  time  passage.  In  particular,  the  value  of  last_l  is  the  same  at  s_4  as  it  was  at  s_3. 

(APPLY -LEMMA  “last-1 -interval”  (“A-l”  “B_glb”))  * 

(NORMALIZE-ATEXECS)  *  (2.1) 

(APPLY  (THEN  (REPLACE  -2)  (REPLACE  -3))  * 

“Using the  names  s_3  and S-4”)  * 

;  Supposition  4:  Now(s_4)  =  t(A_l)(B_glb+l). 

(CASE  “Now(s-4)  =  t(A_l)(B-glb+l)”) 

((“1” 

;  Since  s_4  is  reachable,  we  can  apply  the  invariant  lemma  4_2_1,  which  says  that 
;  now(s_4)  <=  last -l(s_4). 

(GET_RE ACHABLES  “A_l”  “B-glb”)  * 

(APPLY JN V-LEMM A  “4-2-1”  “s.4”)  *  (3.1) 

(APPLY  (HIDE  —2  -3  -4  -5  -6  -7)  * 

“Remove  unneeded  reachability  info.”)  * 

;  But  this  contradicts  what  we  know  about  now(s_4):  namely,  that  Now(s_4)  =  t(A_l)(B-glb+l)  >  B, 
;  last_l(s_4)  =  last_l(s_3),  last-1  (s_3)  =  last_l(s-2)  (because  event  B_glb  has  property  A-hat), 

;  and  last_l(s_2)  <=  B. 

(EXPAND  “Now”) 

(TIME-SIMP  -1)) 

;  Proof  of  Supposition  4:  Follows  from  the  definition  of  s_4  and  standard  simplifications. 

(“2” 

(APPLY  (REPLACE  -2  1  RL) 

“Using  the  def  of  s_4  in  the  subgoal  consequent.”) 
(NORMALIZE-ATEXECS) 

(SIMPLIFY)))) 

;  We  prove  a  TCC  showing  that  B-glb  is  within  the  range  of  values  for  which  property  A-hat  holds, 

;  given  that  B-glb  has  property  A. 

(“2”  (ASSERT)))) 

;  We  now  prove  Supposition  A(B)  by  induction  on  the  variable  m. 

(“2” 

(APPLY  (THEN  (INDUCT  “m”)  (ASSERT)) 

“Note  that  inducting  this  way  avoids  creating  4  subgoals.” 
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“This  is  the  proof  of  assertion  A(B);  rather,  it  is  the  proof 
that  if  assertion  A(B)  is  false,  then  one  can  find  an  enterl 
event  between  Pi  and  B,  which  claim  is  assertion  A(B)’s 
companion  assertion  in  the  subgoal’s  consequent.”) 

;  The  base  case  and  some  TCC’s  were  proved  by  ASSERT,  i.e.,  by  the  decision  procedures, 

;  simplification,  and  propositional  reasoning  in  PVS.  We  prove  the  induction  step. 

(APPLY  (THEN  (SKOLEM  1  (FLATTEN))) 

;  Suppose  that  j_l  is  some  integer  such  that  if  j_l  >  0  and  the  j_l-th  event  is  the  n_l-th  event  or  later 
;  and  comes  before  time  B,  then  j_l  has  property  A.  We  will  show  that  if  the  conclusion  of  lemma_E_l 
;  is  false,  then  if  the  (j  J.  4-  l)-th  event  is  the  nJ.-th  event  or  later  and  comes  before  time  B,  then 
;  j_l  4-  1  has  property  A.  To  do  this,  suppose  that  indeed  the  (j_l  4-  l)-th  event  is  the  n_l-th  event 
;  or  later  and  comes  before  time  B. 

;  If  j_l  4-  1  =  n_l,  it  trivially  has  property  A,  since  pi(A_l)(nJ.)  =  lower  and 
;  last_l(path(w(A_l)(n_l))(t(A_l)(n_l)))  =  last_l(s_2). 

(CASE  “j_l+l  -  n_l”) 

"  ((“1”  (SKOLEM  1  “pJL”)  (FLATTEN)  (ASSERT)) 

;  So  we  may  assume  that  j-1  +  1  is  greater  than  nJL 
(“2” 

;  We  may  then  deduce  that  j_l  >  0  (since  n_l  is  positive),  and  that  j  J.  >=  n_l. 

(ASSERT) 

;  We  may  also  deduce  that  the  j_l-th  event  comes  before  time  B,  because  the  (j_l  4-  l)-th  does. 

(APPLY  (TIME.ORDER  “A.l”  “jJL”  “j_l4-l”)  * 

“This  should  mimic  doing  a  SPLIT  without  getting  * 

a  companion  assertion.” )  *(4.1) 

(ASSERT)  * 

(APPLY  (HIDE  -1)  “Finish  the  mimicking  of  SPLIT.”)  * 

;  Let  p_l  be  some  positive  natural  number.  We  will  show  that  if  n_l  <=  p_l  <=  j_l  4-  1,  then  p_l 
;  has  property  A-hat.  Since  p_l  is  arbitrary,  it  will  follow  that  j_l  4-  1  has  property  A. 

(SKOLEM  2  “p_l”) 

;  By  inductive  hypothesis,  if  n_l  <=  p_l  <=  j_l,  then  p_l  has  property  A-hat. 

(INST  -1  “p_l”) 

;  So,  suppose  that  n_l  <=  p_l  <=  j_l  4-  1. 

(APPLY  (FLATTEN) 

“Note,  above  is  an  instance  of  matched  skolem  4-  inst.”) 

;  Then  if  p_l  is  in  fact  less  than  or  equal  to  j_l,  it  has  property  A-hat. 

(ASSERT) 

;  So,  consider  the  case  that  p_l  =  j_l  4-  1- 

(APPLY  (CASE  “p.l  =  j_l  4-  1”) 

“This  is  the  meaty  case,  since  if  p_l  <  j_l  4-  1,  then  the 
induction  hypothesis,  which  applies  to  all  p_l  between 
n  _1  and  j  JL,  inclusive,  assures  that  last.l  at  p  _1  is 
the  same  as  at  n_l,  and  that  event  p_l  is  not  enterl.”) 

;  Then  we  will  show  that  either  lemma_E_l  holds  with  the  p_l-th  event  being  the  event  Phi  that  comes 
;  after  Pi  and  before  B  that  is  an  enterl,  or  else  p_l  has  property  A-hat. 
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((“!” 

(INST  3  “p.l”) 

(ASSERT) 

;  Since  the  p_l-th  event  is  after  Pi,  this  is  equivalent  to  showing  that  (1)  either  the  p_l-th  event  is  an 
;  enterl  or  p-1  has  property  A-hat  and  (2)  either  the  p_l-th  event  happens  before  B  or  p_l  has  property 
;  A-hat. 

(SPLIT  3) 

;  We  first  prove  (1). 

((“1” 

;  We  recall  that  the  induction  hypothesis  says  that  any  integer  between  n_l  and  j_l  has  property  A-hat. 
(APPLY  (REVEAL  -1) 

“Grab  the  general  form  of  the  induction  hypothesis.”) 

;  This  applies  in  particular  to  j_l  itself. 


(APPLY  (INST  -1  “jJL”) 

“We  now  prepare  to  do  the  real  induction  step  in  this 
proof,  namely,  to  show  that  last-1  is  unchanged  by 
event  j_l  +  1  provided  it  is  not  an  enterl.”) 

(ASSERT) 

;  We  will  show  that  either  the  p_l-th  event  is  an  enterl  or  else  last.l  in  the  state 
;  following  this  event  is  last_l(s_2). 


(APPLY  (SPLIT  3)  * 

“Using  a  SPLIT  to  match  a  complex  expression  that  * 
ASSERT  missed.”)  * 

;  We  first  replace  our  formulation  of  the  assertion  that  the  p_l-th  event  is  an  enterl  (given  as  an 
;  existentially  quantified  expression  over  trains  r  that  might  do  an  enterl  action)  by  the  data-type 
;  recognizer  formulation  of  this  assertion:  enterI?(pi(A_l)(p_l)). 

(APPLY  (CASE  “enterl? (pi(A_l) (p_l))” )  * 

“Expressing  enterl— ness  better.”)  * 


((“1”  *  (G) 

(INST  2  “Itrainof(pi(A_l)(p-l))”)  * 

(APPLY-EXTENSIONALITY  2))  * 

(“2”  * 


;  We  can  now  proceed  with  our  proof.  Since  j-1  has  property  A-hat,  the  value  of  last_l  in  the  state 
;  following  the  j_l-th  event  is  last_l(s_2). 

(FLATTEN) 

;  For  convenience,  we  assign  names  to  certain  states:  S-8  is  the  state  just  after  the  j_l-th  event,  s_9  is 
;  the  state  just  before  the  (j_l  +  l)-th  event,  and  s_10  is  the  state  just  after  the  (j_l  +  l)-th  event. 

(APPLY  (THEN  (NAME  “s_8”  “fstate(w(A_l)(j_l))”) 

(NAME  “s.9”  “lstate ( w ( A _1 )  (j _1 ) ) ” ) 

(NAME  “s-10”  “fstate(w(A-l)(j-l+l))”)) 

“Name  the  states  relevant  to  the  preservation  of 
last-1  from  the  time  of  event  j_l  to  that  of  event 
j_l  +  1.”) 

;  We  note  that  the  value  of  last.l  does  not  change  in  passing  from  s_8  to  s_9. 

(APPLYJLEMMA  “last _1  interval”  (“A_l”  “j_l”)) 

;  We  also  note  that  s-10  is  the  state  reached  by  transitioning  on  the  (j„l  +  l)-th  action  in  state  s_9. 
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(TRANS_FACTS  “A_l”  “j_l”)  * 

(APPLY  (THEN  (REPLACE  -8)  (REPLACE  -9))  * 

“Note  that  trans Tacts  has  invoked  rewriting,  and  * 
thus  accomplished  a  normalize-atexecs.  We  now  use  *  (5.1) 
the  names  s_9  and  s_10,  which  will  also  help  * 

to  find  which  of  the  trans_facts  are  not  needed.”)  * 

(APPLY  (HIDE  -2  -3  -4  -5  -6)  * 

“Hide  the  irrelevant  trans  facts.”)  * 

;  Since  p_l  =  j_l  -1-  1,  we  know  that  what  we  have  to  prove  is  that  either  the  (j_l  -f-  l)-th  event  is  an 
;  enterl  or  else  lastJL(s_10)  =  last-1  (s_2). 

(APPLY  (THEN  (REPLACE  -7)  (REPLACE  -3)) 

“Using  the  equality  of  p_l  to  j_l  4  1  and 
the  definition  of  s_10  to  rephrase  part  of 
the  consequent  to  last_l(s_10)  =  last_l(s_2).”) 

;  We  now  show  that  since  s_10  is  the  result  of  transitioning  on  the  (j_l  4*  l)-th  action  in  state  S-9,  the 
;  desired  conclusion  follows. 

(APPLY  (THEN  (REPLACE  -1  4  RL)  (HIDE  -1))  * 

“Using  the  trans  version  of  s_10  in  the  consequent.”)  *  (6.1) 
(DO.TRANS.OPSPEC))))  * 

;  We  prove  (2):  either  the  p_l-th  event  happens  before  B  or  p-1  has  property  A-hat,  by  showing  that 
;  the  p_l-th  event  indeed  happens  before  B  (because  we  have  supposed  that  the  (j_l  4  l)-th  event 
;  does,  and  we  have  assumed  that  p-1  =  j-1  4  1). 

(“2”  (TIME_SIMP  1)))) 

;  We  now  consider  the  case  p_l  <  j_l  4  1;  but  the  fact  that  the  p-l-th  event  has  property  A-hat  for 
;  any  such  p_l,  which  is  what  we  must  prove,  follows  trivially  from  the  inductive  hypothesis. 

(“2”  (ASSERT)))))))) 

;  We  now  prove  Supposition  3:  B_glb  4  1  >  n_l.  This  follows  from  the  fact  that  the  (B„glb  4  l)-th 
;  event  happens  after  the  n_l-th  event. 

(“2”  (TIME-ORDER  “A_l”  “n_l”  “B_glb  4  1”)  (ASSERT))))  *  (4.2) 

;  We  now  prove  Supposition  2:  last-1  (s-2)  <=  now(s_2)  4  xi-1. 

(“2” 

(HIDE  2) 

;  We  first  isolate  the  fact  that  now(s_l)  =  now(s_2). 

(FLATTEN) 

;  We  adduce  the  fact  that  state  s_2  is  the  result  of  transitioning  on  the  n_l-th  action  Pi  on  state  s_l. 

-  (TRANS-FACTS  “A_l”  “n_l-l”)  * 

:v:  (NORMALIZEJVTEXECS)  * 

(APPLY  (THEN  (REPLACE  -7)  (REPLACE  -8))  “Using  the  names  S-1  and  s_2.”)  *  (5.2) 
(APPLY  (HIDE  -2  -3  -4)  * 

“The  object  here  is  to  hide  all  instances  of  trans  that  * 

are  not  connected  to  s_2  or  are  redundant.”)  * 

;  Applying  these  two  facts,  together  with  the  knowledge  of  the  effect  of  the  lower  action  Pi  in  a  state 
;  in  which  the  gate  is  either  going_up  or  fully _up,  we  see  that  it  is  enough  to  show  that  either 
;  last_l (s_l)  =  infinity  or  else  last_l(s_l)  <=  now(s_l)  4  xi_l. 

(APPLY  (REPLACE  -2) 

“Using  the  fact  that  now(s_2)  —  now(s_l);  note  that  it  is 
critical  to  do  this  before  the  next  step.”) 

(APPLY  (THEN  (REPLACE  -1  4  RL)  (HIDE  -1))  * 

“Using  the  trans  version  of  s_2  in  the  consequent.”)  *  (6.2) 

(DO-TRANS-OPSPEC)  * 
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(APPLY  (MATCH-CONDITION  1) 

“Forcing  the  if-then-else  with  condition  fully.up  or  going.up 
to  simplify  as  if  it  were  recognized  that  the  condition  is 
equivalent  to  going-up  or  fully  .up.”) 

(APPLY  (MATCH-CONDITION  1) 

“This  splits  and  flattens  the  new  if-then-else,  giving  the 
effect  of  case  splitting  on  last-1  (s_l)  =  infinity.”) 

;  In  the  case  last-1  (s_l)  =  infinity,  the  result  is  trivial. 

((“1”  (TIME-SIMP  1)) 

;  So,  we  may  assume  that  last_l(s_l)  <>  infinity. 

(“2” 

;  Now,  state  s_l  is  reachable. 

(APPLY  (GET-REACHABLES  “A.l”  “n-1  -  1”)  * 

“Note  that  this  is  one  case  where  one  wants  to  keep  both  * 

assertions  in  the  consequent.”)  *  (3.2) 

;  Therefore,  we  can  apply  the  invariant  lemma  4-2.3  to  s_l: 

(APPLY JNV-LEMMA  “4-2.3”  “s_l”)  * 

;  which  is  precisely  what  is  required. 

(APPLY  (THEN  (OPSPEC-SIMP.2)  (TIME-SIMP  2)))))))) 

;  Proof  of  Supposition  1:  The  time  of  Pi,  t(A-l)(n.l),  equals  now(s.l)  and  now(s_2).  This  follows 
;  from  standard  equivalences,  the  definitions  of  s.l  and  s_2,  and  standard  PVS  simplifications  and 
;  decision  procedures. 

(“2” 

(APPLY  (HIDE  2)  “Finally  proving  the  time  equivalence  facts.”) 

(APPLY  (THEN  (REPLACE  -1  +  RL)  (REPLACE  -2  +  RL)) 

“Expanding  the  names  s_l  and  s_2  in  the  consequent.”) 

(NORMALIZE.ATEXECS) 

(SIMPLIFY)))) 


E.2  Potential  New  Strategies  for  Lemma  E.l  from  PVS  Enhancements 

In  the  annotated  proof  in  Appendix  E.l,  we  have  indicated  places  where  six  new  strategies  could  be  applied, 
if  we  had  the  tools  in  PVS  to  define  them.  Here,  we  describe  the  effects  (when  successful)  and  possible 
implementation  of  each  of  these  proposed  new  strategies,  and  indicate  how  they  would  be  invoked  at  each 
of  the  indicated  places  in  the  Lemma  E.l  proof.  As  will  be  seen,  all  the  proposed  implementations  require 
naming,  analysis,  and  recognition  capabilities  for  assertions  that  are  not  currently  available  in  PVS.  To 
avoid  repetition,  the  proposed  implementations  omit  mentioning  the  anticipated  use  of  assertion  naming 
by  strategies  that  rely  on  a  lemma;  such  naming  will  aid  in  the  recognition  and  removal  of  redundant  or 
irrelevant  information  generated  from  the  lemma  application.  The  proposed  implementations  also  ignore  an 
important  feature  that  will  need  to  be  incorporated  in  each:  the  generation  of  useful  error  messages. 

(1)  (CONCLUDE  <proposition>  <instantiation>) 

Effect.  Puts  all  conclusions  in  <proposition>,  applied  to  <instantiation>,  in  the  hypotheses  of  the  current 
sequent.  <proposition>  may  be  denoted  by  a  tag  (this  requires  enhancement  to  PVS)  or  by  an  assertion 
number,  and  should  refer  to  a  current  subgoal  antecedent  formula  in  the  form  of  a  universally  quantified 
implication  whose  hypothesis  is  satisfied  by  j instantiation,;,. 

Proposed  implementation.  Implement  by  a  sequence  INST,  MODUS.PONENS,  FLATTEN  focused 
on  < proposition^  which  may  be  indicated  either  by  a  name  rather  than  an  assertion  number. 
MODUSJPONENS  will  be  a  more  sophisticated  version  of  MODUS JPONENS  as  defined  in  Appendix  C; 


67 


it  will  focus  on  removing  the  highest-level  hypothesis  from  an  assertion,  provided  it  can  be  deduced  from 
other  antecedent  formulae  in  a  sequent. 

Invocations  in  the  Lemma  E.l  proof. 

(1.1)  (CONCLUDE  “Claim_A(B)”  “B.glb”) 

(1.2)  (CONCLUDE  wClaim_A(B). conclusion”  “B_glb”) 

(1.3)  (CONCLUDE  “ClaimJV(B)Jnd-hyp” 

Comments.  We  have  used  assertion  names  rather  than  assertion  numbers  in  these  example  invocations. 
It  is  anticipated  that  the  assertion  name  “Claim_A(B)”  would  be  provided  by  the  user  at  the  time  this 
particular  assertion  was  introduced  using  CASE.  Names  of  the  related  assertions  would  be  automatically 
generated  according  to  the  structure  of  the  original  assertion  (as  in  “Claim_A(B) .conclusion”)  or  as  the 
result  of  its  manipulation  by  other  strategies  (such  as  the  call  to  “(INDUCT  “m”)”,  that  locates  and 
then  operates  on  assertion  “Claim_A(B)”). 

If  one  uses  ASSERT  instead  of  MODUS-PONENS,  the  invocation  (1.1)  will  handle  an  associated  TCC 
automatically.  The  proposed  implementation  of  CONCLUDE  probably  will  be  modified  to  maximize 
the  set  of  cases  in  which  this  will  happen. 

(2)  (SAMEVAL  <component_name>  <state_l>  <state_2>) 

Effect.  Adds  the  fact  that  the  state  function  or  component  <  component  .name  >  has  the  same  value  at 
<state_l>  and  <state_2>  to  the  hypotheses  of  the  current  goal. 

Proposed  implementation.  The  implementation  must  rely  on  the  existence  of  a  lemma  about 
<component_name>  with  a  standard  derived  name  that  guarantees  that  < component _name>  is  con¬ 
stant  in  a  trajectory.  State  arguments  that  are  simply  names  may  have  to  be  looked  up  in  the  visible 
or  hidden  part  of  the  antecedent  hypothesis  list  to  determine  the  appropriate  relevant  atexecs  and  nat 
instantiations  for  the  lemma,  and  to  replace  the  states  in  the  conclusion  of  the  lemma  by  their  names. 

Invocations  in  the  Lemma  E.l  proof. 

(2.1)  (SAMEVAL  “last.l”  “s_3”  “s_4”) 

Comments.  Automatic  generation  and  proof  of  the  necessary  supporting  lemmas  is  a  possibility. 

(3)  (INVARIANT  <invjiame>  <state>) 

Effect.  Adds  the  fact  that  invariant  <inv_name>  holds  for  <state>  to  the  hypotheses  of  the  current  goal. 

Proposed  implementation.  Use  GET_REACHABLES  to  retrieve  information  about  the  reachability  of 
states  in  the  neighborhood  of  <state>.  This  neighborhood  can  be  deduced  from  the  arguments  of  types 
atexecs  and  nat  in  the  representation  of  <state>,  which,  in  turn,  will  either  be  explicitly  present  or 
retrievable  from  some  visible  or  hidden  equality  in  the  current  goal.  This  information  can  be  retrieved, 
used  in  the  call  to  APPLYJNV_LEMMA,  and  then  hidden. 

Invocations  in  the  Lemma  E.l  proof. 

(3.1)  (INVARIANT  “4J2_I”  “s_4”) 

(3.2)  (INVARIANT  “4_2_3”  “s_l”) 

Comments.  The  retrieval  of  reachability  information  about  <state>  could  include  a  check  on  whether  this 
information  is  present  in  either  the  visible  or  hidden  part  of  the  current  goal,  if  this  increases  efficiency. 

(4)  (TIMEJRELATION  <indexJL>  <index_2>) 

Effect.  Puts  the  fact  that  event  <index_l>  comes  before  event  <index_2>,  or  vice-versa  (whichever  is 
correct)  in  the  hypotheses  of  the  current  goal. 


Proposed  implementation.  Use  the  strategy  TIME-ORDER,  followed  by  ASSERT  (to  deduce  and  apply 
the  appropriate  inequality  between  <index-l>  and  <index-2>);  then  hide  or  delete  the  extra  assertion 
generated  (that  relates  to  the  “inappropriate”  inequality). 

Invocations  in  the  Lemma  E.l  proof. 

(4.1)  (TIME_RELATION  “j-1”  “jJL  +  1”) 

(4.2)  (TIME-RELATION  VI”  “B_glb  +  1”) 

Comments.  An  argument  of  type  atexecs  may  also  be  added  to  this  strategy.  The  alternative  is  to  provide 
some  means  to  retrieve  the  appropriate  instantiation  or  instantiations  from  the  current  goal.  When 
reasoning  about  properties  of  one  timed  automaton,  there  will  typically  be  only  one  such  instantiation. 
When  reasoning  about  simulations  between  timed  automata,  there  may  be  two. 

(5)  (TRANS-RELATION  <state_l>  <state_2>) 

Effect.  Puts  the  fact  that  <state_2>  is  the  result  of  a  transition  from  <state-l>,  or  vice-versa,  in  the 
antecedent,  with  an  instantiation  of  the  action  associated  with  the  transition. 

Proposed  implementation.  The  neighborhood  of  <state-l>  and  <state_2>  (that  is,  the  relevant  atexecs 
and  nat  values)  are  retrieved  either  directly  or  by  looking  state  names  up  in  the  visible  or  hidden  part 
of  the  antecedent  of  the  current  goal.  The  strategy  TRANS-FACTS  can  then  be  invoked  to  get  all  likely 
candidates  for  the  transition  relation.  State  values  are  then  normalized  by  NORMALIZE-ATEXECS, 
and  those  equal  to  <state-l>  and  <state-2>  are  replaced  by  <state-l>  and  <state-2>.  Irrelevant 
or  redundant  assertions  generated  by  TRANS-FACTS  are  then  removed;  these  are  recognized  by  a 
combination  of  name  and  content. 

Invocations  in  the  Lemma  E.l  proof. 

(5.1)  (TRANS-RELATION  “s_9”  “s_10”) 

(5.2)  (TRANS-RELATION  “s-1”  “s-2”) 

Comments.  If  <state_l>  and  <state_2>  are  expressions  rather  than  names,  replacing  equal  state  values  by 
these  names  will  require  some  care,  since  these  expressions  may  be  altered  by  NORMALIZE-ATEXECS. 

(6)  (COMPUTE.TRANS  <state>  <assertion>) 

Effect.  Replaces  <state>  in  <assertion>  by  its  value  computed  as  the  result  of  a  transition. 

Proposed  implementation.  If  the  representation  of  < state >  as  the  result  of  at  transition  is  present  in 
the  antecedent  of  the  current  goal,  it  can  be  recognized,  and  used  to  replace  <state>  in  <assertion>.  A 
version  of  DO.TRANS  that  focuses  only  on  <assertion>  can  then  be  applied. 

Invocations  in  the  Lemma  E.l  proof. 

(6.1)  (COMPUTE-TRANS  “s-10”  “Claim_A(B)Jnd_concr) 

(6.2)  (COMPUTE.TRANS  “s_2”  “Supposition_2” ) 

Comments.  DO-TRANS  is  timed-automaton-dependent,  since  it  calls  the  standard  simplification  strategy 
of  the  timed  automaton  in  which  the  transition  takes  place.  However,  the  name  of  the  timed  automaton, 
and  hence  that  of  its  simplification  strategy,  could  be  deduced  from  the  type  information  for  <state>. 

Note  that  we  have  marked  one  sequence  in  the  proof  of  Lemma  E.l  with  an  “(G)”.  At  point  “(G)”, 
the  representation  of  a  certain  fact  in  the  sequent  is  changed  by  supplying  a  rather  cryptic  instantiation 
and  applying  the  PVS  strategy  APPLY-EXTENSIONALITY.  Both  representations  of  the  particular  fact 
correspond  to  the  same  high-level  English  language  description  “the  p_l-th  event  is  an  enterl  event”.  Thus, 
sequence  “(G)”  does  not  exactly  correspond  to  any  step  in  an  English  language  proof  of  Lemma  E.l;  the  need 
for  it  in  the  PVS  proof  is  really  an  artifact  of  the  representation  in  PVS  of  the  timed  automaton  OpSpec. 
“(G)”  may  be  one  example  of  a  point  where  a  certain  amount  of  “PVS  glue”  is  required  in  translating  from 
hand  proof  to  PVS. 
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F  Appendix.  A  Second  PVS  Template  for  Timed  Automata 

The  theory  timed_auto_decls,  if  used  as  one  of  the  fixed  underlying  template  theories,  is  designed  to  allow 
the  PVS  typechecker  to  enforce  many  of  the  template  conventions,  such  as  the  existence  of  a  time  passage 
action,  the  usage  of  the  separate  parts  of  enabled ,  the  fact  that  the  now  component  of  a  start  state  must 
be  zero,  and  so  on.  It  has  an  accompanying  theory,  timed^auto_thy,  which  we  do  not  show  since  it  is 
essentially  identical  to  the  theory  opspec_strat_aux  (see  Appendix  B.3). 

One  of  the  benefits  of  including  the  two  theories  among  the  fixed  template  theories  is  that  the  lemmas 
in  timed_auto_thy  become  independent  of  the  automaton  being  specified,  and  can  be  pre-proved  prior  to 
specifying  any  particular  timed  automaton.  They  do  not  then  have  to  be  re-proved  in  order  to  be  used  (by 
way  of  our  specialized  strategies  or  otherwise)  in  constructing  “guaranteed  sound”  PVS  proofs  of  properties 
of  a  particular  timed  automaton. 

We  first  present  the  theory  timed_auto_decls,  and  then  show  how  the  timed  automaton  OpSpec  would 
be  defined  in  PVS  using  the  resulting  new  template. 

F.l  Appendix.  The  Theory  timed_auto„decls 


fimed_auto_decls  [  basic-states,  actions:  TYPE, 

%  Importing  time.thy  defines  the  type  “time”  that  behaves  like  the  non-negative 

%  reals  except  for  having  an  infinite  value  included. 

(IMPORTING  time.thy, 

%  Importing  states[...]  defines  the  type  states,  whose  elements  are  records  with 

%  indices  “basic”  (basic_states),“now”  (a  (fintime?)  value),  “first”  and  “last” 

%  (maps  from  actions  to  time). 

states[actions,basic_states, time, fintime?]) 
nu:  [(fintime?)  ->  actions], 
nu?:  [actions  ->  bool], 
timeof:  [(nu?)  ->  (fintime?)], 

%  The  “start”  predicate  on  states  is  split  into  three  parts  to  emphasize  its 

%  structure  and  to  enforce  “now(s)  =  zero” . 

basic_start:  [basic_states  ->  bool], 
first-start:  [basic^states, actions  ->  time], 
last_start:  [basic  .states, act  ions  ->  time], 

%  The  “trans”  operation  of  actions  on  states  is  also  split  into  three  parts  to 

%  emphasize  its  independence  from  “now”  except  in  the  special  case  of  a 

%  time-step  action  nu. 

basic.trans:  [[actions, states]  ->  basic-states], 
first.trans:  [[actions, states]  ->  [actions->time]], 
last  .trans:  [[actions, states]  ->  [actions- >  time]], 
enabled_specific:  [[act ions, states]  ->  bool], 

OKstate?:  [states  ->  bool]  ]  :  THEORY 

%  The  theory  timed_auto_decls  is  the  main  template  specification  for  timed  automata.  Instantiation 
%  of  this  template  is  done  by  importing  the  companion  specification  timed _auto_thy  with  the 
%  appropriate  parameters. 

%  The  expected  instantiations  of  the  specification  parameters  to  timed_auto_decls  and  timed_auto_thy 
%  are  as  follows: 

%  basicjstates:  some  encoding  of  that  part  of  the  states  that  is  separate  from  the  “now” 

%  component  (a  time  value)  and  the  “first”  and  “last”  components  (maps  from  actions 

%  (events)  to  time). 
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%  actions:  an  abstract  data  type  whose  members  are  actions,  that  contains  a  “nu”  action 
%  parameterized  by  (non-zero,  non-infinite)  time. 

%  nu:  the  time-step  element  of  “actions”,  parameterized  by  “(fintime?)” 

%  nu?:  a  predicate  on  actions  that  identifies  just  when  an  action  is  a  “nu”  time-step  action. 

%  timeof:  extracts  the  “time”  parameter  from  time-step  actions. 

%  basic-start:  the  predicate  that  identifies  the  basic  parts  of  start  states. 

%  first-start:  the  function  that  maps  states  and  actions  to  the  initial  “first”  value  for  that 
%  action  with  respect  to  the  basic  part  of  the  state. 

%  last-start:  the  function  that  maps  states  and  actions  to  the  initial  ‘last”  value  for  that 
%  action  with  respect  to  the  basic  part  of  the  state. 

%  basic-trans:  this  is  the  part  of  “trans”  that  does  not  deal  with  changes  to  “now”,  “first”  and 
%  “last”. 

%  first-trans:  this  is  the  part  of  “trans”  that  describes  how  one  action  affects  the  “first”  time  of 
%  another. 

%  last.trans:  this  is  the  part  of  “trans”  that  describes  how  one  action  affects  the  “last”  time  of 
%  another. 

%  enabled-specific:  this  is  the  part  of  enabled  that  maps  an  action  to  the  non-default  part  of  the 
%  pre-condition  predicate  on  the  state. 

%  OKstate?:  this  is  a  predicate  on  states  that  can  be  used  to  enforce  one  or  more  state  invariants 
%  by  restricting  the  reachable  states  directly. 

BEGIN 

%  Before  importing  atexecs,  one  needs  to  define  start,  Now,  step?,  and  nu;  step?  depends  on  the 

%  definitions  of  enabled  and  trans,  so  must  define  these  also.  Note  that  one  can  then  go  ahead  and 

%  import  machine  as  well. 

start(s:states):bool  =  (s  =  (#  basic  :=  basic(s), 

now  :=  zero, 

first  :=  (LAMBDA (auctions):  first.start(basic(s),a)), 
last  :=  (LAMBDA(a:actions):  last-start(basic(s),a))  #) 

&  basic_start(basic(s))  ); 

Now(s:states):{r:real  |  r  >=  0}  =  dur(now(s)); 

Nu  (z:  {z:real  |  z>0}):  actions  =  nu(fintime(z:  {z:real  j  z>=0})); 

trans(a:actions,s:states):states  = 

IF  nu?(a)  THEN  s  WITH  [now  :=  now(s)  +  timeof(a)] 

ELSE  s  WITH  [basic  :=  basic_trans(a,s), 

first  :=  (LAMBDA(b:actions):first.trans(b,s)(a)), 
last  :=  (LAMBDA(b:actions):last_trans(b,s)(a))] 

ENDIF; 

enabled-general  (a:actions,s:states)  :bool  = 

IF  nu?(a)  THEN  dur(timeof(a))  >  0  ELSE  first(s)(a)  <=  now(s)  &  now(s)  <=  last(s)(a)  ENDIF; 
enabled  (a:  actions  ,s :  st  ates)  :bool  = 

enabled-general(a,s)  &  enabled_specific(a,s)  &  OKstate?(trans(a,s)); 
step?  (sl:states,  auctions,  s2:states):  bool  =  enabled(a,sl)  &  s2  =  trans(a,sl); 

IMPORTING  atexecs  [states,  actions,  start,  Now,  step?,  Nu] 

IMPORTING  machine[states,  actions,  enabled,  trans,  start] 

END  timed_auto_decls 
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F.2  Appendix.  The  Timed  Automaton  OpSpec  in  PVS:  Version  2 

The  specification  of  the  theory  opspec  in  the  alternative  template  (and  actually,  the  new  template  itself)  is 
rather  more  messy,  than  the  specification  in  B.3,  since  certain  functions  have  been  decomposed  into  several 
functions.  However,  at  least  some  of  this  messiness  could  be  hidden  by  an  appropriate  interface  external  to 
PVS. 


opspec-decls:  THEORY 
BEGIN 
train:  TYPE 
r,rl:  VAR  train 
IMPORTING  time.thy 

beta_posreal:  {r:real  |  r  >  0}; 
delta_t:  VAR  (fintime?) 

eps_l,  eps_2,  gamma.down,  gamma.up,  xLl,  xi_2,  delta:  (fintime?) 
beta: (fintime?)  =  fintime (beta_posreal:{r:real  |  r  >=  0}); 

const  Tacts:  AXIOM  (  eps.l  <=  eps-2 

&  eps.l  >  gamma_down 

&;  xLl  >=  gamma-down  4-  beta  +  eps_2  —  eps_l 
&  xi-2  >=  gamma-up  ); 

actions  :  DATATYPE 
BEGIN 

nu(timeof: (fintime?)):  nu? 
enterR(Rtrainofitrain):  enterR? 
enterI(Itrainof: train):  enterl? 
exit(Etrainof:train):  exit? 
lower:  lower? 
raise:  raise? 
up:  up? 
down:  down? 

END  actions; 

a:  VAR  actions; 

train_status:  TYPE  =  {not_here,P,I}; 

gate_status:  TYPE  =  {  fully  _up, fully -down, going-up, going_down}; 

basic-states:  TYPE  =  [#  trains_part:  [train  —  >  train_status], 

gate_part:  gate_status, 

last_l-part,  last-2_up_part,  last_2J_part:  time  #]; 

IMPORTING  states  [actions,  basic_states,  time,  fintime?] 

si:  VAR  states; 
b:  VAR  basic_states; 

status(r:train,  s:states):train_status  —  trains_part(basic(s))(r); 
gate_status(s:states):gate_status  =  gate_part(basic(s)); 
last_l(s:states):time  =  last  _1  .part  (basic  (s)); 
last_2_up(s:states):time  =  last-2_up_part(basic(s)); 
last_2J(s:states):time  =  last_2J_part(basic(s)); 

OKstate?  (s:states):  bool  —  ((EXISTS  (r:train):  status(r,s)  =  I)  =>  gate_status(s)  =  fully.down); 
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enabled  .specific  (a:actions,  s:states):bool  = 

CASES  a  OF 

enterR(r):  status(r,s)  =  not-here, 
enterl(r):  status(r,s)  =  P  &  first(s)(a)  <=  now(s), 
exit(r):  status(r,s)  =  I, 
nu(delta_t):  (delta.t  >  zero 

&  (FORALL  r:  now(s)  4-  delta.t  <=  last(s)(enterl(r))) 

&  now(s)  +  delta_t  <=  last(s)(up) 

&  now(s)  4-  delta_t  <—  last(s)(down) 

&  now(s)  4-  delta.t  <=  last_l(s) 

&  now(s)  4-  delta.t  <=  last_2_I(s)), 

lower:  true, 
raise:  true, 

up:  gate_status(s)  =  going.up, 
down:  gate_status(s)  =  going_down 
ENDCASES; 

basic-trans  (a:actions,  s:states):basic.states  = 

CASES  a  OF 

enterR(r) :  basic(s)  WITH  [trains.part  :=  trains-part  (basic  (s))  WITH  [r  :=  P]], 
enterl(r):  basic(s)  WITH 

[trains_part  :=  trains.part(basic(s))  WITH  [r  :=  I], 
last-l_part  infinity, 
last_2_up_part  :=  infinity, 
last_2JLpart  :=  infinity], 

exit(r):  LET  b  =  basic(s)  WITH  [trains_part:=  trains.part (basic (s))  WITH  [r:—  notJiere]] 
IN  IF  (FORALL  (rl:  train):  (NOT  (rl  =  r))  =>  (NOT  status(rl,s)  =  I)) 

THEN  b  WITH 

[last_2_up_part  :=  now(s)  4-  xi_2, 
last_2_I_part  :=  now(s)  4-  xi_2  4-  delta  4-  xi_l] 

ELSE  b  ENDIF, 
nu (delta.t):  basic (s), 

lower:  IF  gate_status  (s)  =  fully _up  OR  gate_status(s)  =  going.up 
THEN  LET  b  =  basic(s)  WITH  [gate_part  :=  going_down] 

IN  IF  last_l(s)  =  infinity 

THEN  b  WITH  [last_l_paxt:=:  now(s)-fxi_l] 

ELSE  b  ENDIF 
ELSE  basic(s)  ENDIF, 

raise:  IF  gate_status(s)  =  fully.down  OR  gate^status(s)  =  going.down 
THEN  basic (s)  WITH  [gate.part  :=  going.up] 

ELSE  basic(s)  ENDIF, 

up:  LET  b  =  basic(s)  WITH  [gate_part  :=  fully _up] 

IN  IF  now(s)  <=  last_2_up(s) 

THEN  b  WITH  [last_2_up.part:=  infinity,  last_2JLpart:=  infinity] 

ELSE  b  ENDIF, 

down:  basic(s)  WITH  [gate_part  :=  fully  .down] 

ENDCASES 

first.trans  (auctions,  s:states) :  [actions— > time]  = 

CASES  a  OF 

enterR(r):  first(s)  WITH  [(enterl(r))  :=  now(s)  4-  eps.l], 
enterl(r):  first (s)  WITH  [(enterl(r))  :=  zero] 

ELSE  first(s) 

ENDCASES 
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last-trans  (a: actions,  s: states) : [actions— > time]  = 

CASES  a  OF 

enterR(r):  last(s)  WITH  [(enterl(r))  :=  now(s)-f-eps_2], 
enterl(r):  last(s)  WITH  [(enterl(r))  :=  infinity], 
exit(r):  last(s), 
nu(delta_t):  last(s), 

lower:  IF  gate_status  (s)  =  fully _up  OR  gate-status  (s)  =  going_up 

THEN  last(s)  WITH  [down  :=  now(s)+gamma_down,  up  :=  infinity] 
ELSE  last(s)  ENDIF, 

raise:  IF  gate_status(s)  =  fully  „down  OR  gate_status(s)  =  going_down 

THEN  last(s)  WITH  [up  :=  now(s)+gamma_up,  down  :=  infinity] 
ELSE  last(s)  ENDIF, 
up:  last(s)  WITH  [up  infinity], 
down:  last(s)  WITH  [down  infinity] 

ENDCASES 

basic_start  (b:basic_states):bool  = 

b  =  (#  trains-part  :=  (LAMBDA  r:  not-here), 
gate-part  :=  fully  _up, 
last  _1  .part  :=  infinity, 
last_2_up_part  :=  infinity, 
last_2JLpart  :=  infinity  #); 

first_start  (b:basic_states,  auctions)  :time  =  zero; 
last_start  (b:  basic  .states,  auctions)  :time  =  infinity; 

IMPORTING  timed_auto_thy  [  basicjstates,  actions,  nu,  nu?,  timeof, 

basic_start,  first_start,  last_start, 
basic.trans,  first  Trans,  last.trans, 
enabledjspecific,  OKstate?] 

END  opspec_decls 
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